Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Give each API operation a finite timeout, record a timeout as its own run outcome, and set a separate deadline for the whole benchmark if it must finish within a bounded time. In an asyncio benchmark, timeout handling relies on cancellation; clean up resources in finally and normally let cancellation propagate. That prevents one pending request from silently holding up results without disguising the failure as a success.
The title’s 1,000-run figure describes the scenario, not a verified measurement or a benchmark result. The right timeout depends on the client, endpoint, and service-level expectation; there is no universal value to copy.
Why one hung API call can stall the benchmark
A benchmark that waits indefinitely for every request can stop producing useful results when even one request never completes. This is especially damaging when the harness treats all runs as one batch: one pending operation may prevent the batch from reaching its reporting or completion step.
A timeout addresses the wait, but it does not make the request successful. The benchmark should finish that run with a timeout outcome, retain the elapsed time and any other completed runs, and make the failure visible in its report.
#1 Best Overall
Set an API call timeout at the client boundary
Prefer the HTTP client’s timeout controls when they let you bound the relevant network phases. A client timeout can cover details such as establishing a connection, waiting for a response, sending data, or waiting for an available pooled connection. Those budgets need not all be identical.
HTTPX
HTTPX documents a default timeout after five seconds of network inactivity. That is an inactivity timeout, not a guarantee that the entire request will finish within five seconds. Configure a client-level or per-request timeout, and use separate connect, read, write, and pool limits when the benchmark needs different budgets for those phases. See the HTTPX timeout documentation.
aiohttp
aiohttp’s stable quickstart documents defaults of 300 seconds for total request time and 30 seconds for socket connection. Its ClientTimeout options distinguish total operation time, connection or pool acquisition, socket connection, and the interval allowed between data chunks. Set the timeout on the session or request to match the benchmark’s needs, and check the documentation for the installed version before relying on defaults: aiohttp timeout documentation.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
These defaults are library-specific examples, not recommended values for every service. Choose a request budget based on how long a valid response is expected to take and how long the benchmark can reasonably wait.
Use asyncio timeouts without swallowing cancellation
At the asyncio level, asyncio.timeout() is available starting in Python 3.11. asyncio.wait_for() also applies a timeout by cancelling the awaited operation and raising TimeoutError. Neither should be treated as an unconditional hard wall-clock cutoff: wait_for() waits for cancellation to complete, so the awaited operation’s cleanup can extend the total elapsed time beyond the timeout value.
Use try/finally for cleanup such as releasing local resources. If code catches asyncio.CancelledError to perform cleanup, re-raise it rather than converting cancellation into an ordinary success or error result. Python’s 3.13 documentation warns that “The asyncio components that enable structured concurrency, like asyncio.TaskGroup and asyncio.timeout(), are implemented using cancellation internally and might misbehave if a coroutine swallows asyncio.CancelledError.” Read the Python 3.13 asyncio task documentation.
Rank #3
Example: record an outcome for each run
This example illustrates the outcome boundary; adapt the timeout mechanism and exception handling to the Python version and HTTP client in use. It is not a tested benchmark implementation.
async def one_run(client, request):
started = time.monotonic()
try:
async with asyncio.timeout(REQUEST_BUDGET_SECONDS):
response = await client.send(request)
response.raise_for_status()
return {"status": "ok", "elapsed": time.monotonic() - started}
except TimeoutError:
return {"status": "timeout", "elapsed": time.monotonic() - started}
except Exception as exc:
return {
"status": "error",
"error_type": type(exc).__name__,
"elapsed": time.monotonic() - started,
}Do not turn cancellation into a normal run result in a broad exception handler. Handle it separately only when cleanup is necessary, then propagate it. That leaves the benchmark’s orchestration layer able to apply its own cancellation policy.
Give the benchmark an overall deadline too
A per-request timeout limits how long an individual operation may wait; it does not necessarily bound the entire benchmark. A run-level deadline is useful when the harness must eventually stop, for example when queued work, retries, or cleanup can otherwise keep the process alive. Keep the two budgets conceptually separate:
- Request budget: bounds an individual API operation and allows that run to be reported as timed out.
- Benchmark deadline: bounds the overall run and may end work that has not completed.
When the overall deadline expires, preserve results already collected and mark unfinished work as cancelled or incomplete rather than counting it as successful. Since cancellation cleanup can take time, an asyncio timeout around the whole benchmark is not necessarily an exact process-exit deadline.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose whether one failed request should stop the other runs
Asyncio’s concurrency constructs have different failure-containment behavior. Choose based on whether benchmark runs are independent measurements or a unit of dependent work.
| Approach | What happens when a child raises | When it fits |
|---|---|---|
asyncio.TaskGroup |
Remaining scheduled tasks are cancelled when a child task raises. | Use when the work is dependent or the benchmark should fail fast. To preserve independent run outcomes, catch and convert expected per-run failures inside each worker. |
asyncio.gather() |
An exception from one awaitable does not automatically stop the others; they can continue running. | Use when other runs should continue, but retain task references and deliberately collect results or exceptions so work and failures are not lost. |
These behaviors are described in the Python 3.13 asyncio task documentation. For a benchmark intended to report every independent run, handle expected request failures inside each worker and return a structured outcome. For dependent steps where continuing would make results meaningless, fail-fast cancellation may be the correct policy.
Keep results honest and interpretable
Store each run’s result separately instead of reducing a batch to a single success flag. At minimum, distinguish these outcomes:
- Success: the request completed and passed the benchmark’s success checks.
- HTTP error: a response arrived but did not satisfy the expected status or validation.
- Timeout: the request exceeded its configured budget.
- Cancellation: the run was cancelled, for example by the overall deadline or fail-fast policy.
- Elapsed time: record how long the run took, including for failures where timing is useful.
Do not automatically retry a timed-out request that might have caused a side effect unless the endpoint and client have an idempotency or deduplication strategy. A timeout only establishes that the client stopped waiting; by itself, it does not establish whether the server performed the operation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →
