Quick answer
Concurrency is how many requests are in flight. Dispatch rate is how quickly your client starts them. Completion rate is how many finish and meet your acceptance contract. A lane count answers the first question; it does not by itself answer the other two.
Use this worksheet to estimate a starting point, then measure the workload. For the timing log and batch summary, use the latency measurement guide. This page does not introduce a second scheduler, claim unlimited throughput, or promise a queue-free service.
Define the unit before calculating capacity
| Unit | Example task boundary |
|---|---|
| SERP attempt | One sent request, whether it eventually succeeds or fails |
| Accepted SERP request | A completed response that passes HTTP, business-code and required-field checks |
| Reader request | A separate request for selected source-page content |
| Accepted answer | An application outcome after search, reading and generation pass its own checks |
Do not count a timeout as a confirmed refund or a confirmed successful request. A client stopping its wait does not determine the final server-side outcome. Keep attempt IDs and reconcile the actual account record when investigating billing.
Use a steady-workload approximation transparently
For a stable observation window, a planning relation is mean in-flight requests ≈ completion rate × mean request duration. Use a rate and duration from the same population and window. If your duration includes network and response handling, the result estimates client-observed in-flight work, not a measurement of the provider’s internal lane occupancy.
import math
def estimate_inflight(accepted_requests_per_s, mean_client_request_s):
values = (accepted_requests_per_s, mean_client_request_s)
if any(isinstance(v, bool) or not isinstance(v, (int, float))
or not math.isfinite(v) or v <= 0 for v in values):
raise ValueError("Use finite positive rate and duration inputs")
expected = accepted_requests_per_s * mean_client_request_s
if not math.isfinite(expected):
raise ValueError("Input product is too large")
return {"estimated_mean_inflight": expected,
"rounded_planning_count": math.ceil(expected),
"provider_capacity_guarantee": False}
if __name__ == "__main__":
# Assumed steady rate and duration; not measured SearchCans capacity.
print(estimate_inflight(2, 1.5))
The assumed inputs of two accepted requests per second and 1.5 seconds per request produce an estimated mean of three in-flight requests. They are synthetic inputs, not measured SearchCans performance. Rounding that mean up to three is a planning count, not proof that three lanes will meet a tail-latency target.
Know when the approximation breaks
- A growing backlog is not a steady window. Report arrival rate and backlog growth instead of presenting the mean relation as a capacity guarantee.
- Mean duration does not describe a burst or a long tail. Test the actual timeout and retry policy with a controlled workload.
- If failures occupy substantial time, use total attempt arrival/completion and duration consistently, or model success and failure populations separately.
- Search, extraction and model generation have different service times and acceptance states. Do not multiply an answer rate by a search-only duration.
Map the estimate to the current product contract
SearchCans uses Parallel Lanes for simultaneous requests rather than an hourly request quota. Available capacity and product terms come from the current plan table. A credit pack is a spending allowance; it is not an observed completion rate. No hourly cap does not remove concurrency limits, source-site constraints or request failures.
The Google Search API returns structured search results. Reading the selected pages is a separate Reader operation. If a workflow reads several pages after every search, include that downstream work before increasing search dispatch.
Accept the capacity change with evidence
- Choose an allowed client concurrency, a bounded workload and an explicit stop condition.
- Log queued, started and ended times, response state and whether the result met the application contract.
- Compare accepted request completion, failures, queue growth and end-to-end answer acceptance.
- Increase capacity only when the observed bottleneck and service limits support it; retain the previous setting for rollback.
The worksheet and its edge cases were checked locally on November 1, 2026. Its insight is the separation of units and observable assumptions. It reports no production benchmark, provider SLA or validated maximum.