Choose a repeatable slow workflow and record its normal traffic conditions. Use instrumentation that avoids capturing secrets or unnecessary customer payloads.

1. Measure total response time and divide the request into useful stages such as application startup, database work, external calls and rendering.

2. Record durations with a correlation identifier so one request can be followed across safe logs or traces.

3. Compare typical and slower requests, including tail latency. Check whether delays come from one dependency, accumulated calls or waiting for a connection or worker.

4. Change one relevant factor, such as reducing redundant queries or adding a bounded timeout, and repeat the same workload.

5. Monitor error rate and resource use alongside speed so a faster failure or reduced correctness is not mistaken for an improvement.

Wrap an existing application operation with a duration measurement. In this Python fragment, fetch_stock_from_provider is your already authorised provider call and logger is the application logger. Keep the request payload and credentials out of the timing message.

from time import perf_counter

started = perf_counter()
try:
    stock = fetch_stock_from_provider(product_id)
finally:
    elapsed_ms = round((perf_counter() - started) * 1000, 1)
    logger.info('stock_lookup_duration_ms=%s', elapsed_ms)

Compare this duration with the full request time using the same safe correlation identifier. If the request takes 2,400 ms and this call accounts for 2,100 ms, database tuning is unlikely to explain most of that delay. Also distinguish slow successes from fast failures.

Expected result: A repeatable baseline identifies the time-consuming stage. After a targeted change, the same workload improves without a higher error rate or stale stock information.

Confirm the identified slow stage accounts for the observed delay and that the proposed change improves the actual user workflow. Keep the measurements with the release record.

If only public requests are slow, compare DNS, TLS, proxy and application timing. A local benchmark that bypasses those layers answers a different question.

• Choosing a database connection pool size
• Applying HTTP timeouts and limited retries to an API client
• Choosing FastAPI workers within a memory budget
• Choosing a health check that reflects user-visible failure

• OpenTelemetry tracing concepts
• MDN Server-Timing

• Python monotonic performance timers