Why your API is slow: measuring p95, SQL queries, and external calls
Published on 2026-10-26 by frfrand
Investigate real latency with logs, tracing, and percentiles
"The API takes 120 ms on average" can sound great, until one in twenty users takes several seconds. The 95th percentile (p95) helps you see that slow tail that the average hides.
Let's bring it down to earth: what it means, how to test it, and what happens when you use it with real clients or information. Most problems aren't fixed with a magic button, but with steps you can repeat and measure.
What is API Latency p95 and why it matters
Total API latency can include connection, authentication, SQL queries, calls to external providers, and serialization. p95 indicates the value below which approximately 95% of the observations in the measured set fall. It must be analyzed per endpoint and time window.
One thing is for a demo to work for five minutes and another is to sustain a service every day. For that you need limits, permissions, activity logs, and procedures to resolve failures without improvising.
Implementation or diagnosis example
# Medición puntual desde cliente; no reemplaza observabilidad
curl -sS -o /dev/null -w 'total=%{time_total} code=%{http_code}\n' https://api.ejemplo.com/health
# En backend registrar, sin datos sensibles:
# request_id, ruta_normalizada, status, duracion_ms
# Investigar queries con EXPLAIN ANALYZE en SELECTIt is a didactic reference, not a template you should blindly run in production. Replace the example values, choose identities with minimal permissions, and make sure no sensitive key ends up in a log or repository.
How I would put it to work
- Measure p50, p95, p99, error rate, and request volume per route.
- Record SQL and external call times with request IDs without exposing tokens.
- Reproduce real load: an empty
/healthroute does not measure checkout. - Attack the slowest component and compare before and after.
- Verify that optimizing a route has not worsened memory consumption or writes.
After each step, verify a concrete result: an authorized action, an HTTP status, a processed task, a recorded cost, or a stable metric. If something does not work, check what the first failure was before retrying in a loop.
An example that may appear in a real project
A rental website responds quickly when listing properties, but confirming reservations takes 2 seconds due to an external payment API. Changing VPS does not fix that call; it may be better to decouple jobs and control timeouts.
If that application has multiple clients, separate contexts and resources. It is especially important when a chatbot or an agent can query data: the ease of connecting tools must not bypass privacy and authorization limits.
The most common mistake
Do not compare a p95 calculated with 10 requests with another from 100,000 and conclude that the second is worse. It requires an appropriate window, traffic, and distribution.
A configuration with good defaults helps, but does not eliminate the need for testing. For services that write data or trigger actions, consider retries, duplicates, and midway failures.
Where does ArduMaker come in?
With ArduMaker you can manage APIs and PostgreSQL on VPS, and combine logs and metrics to decide whether to optimize SQL, change concurrency, or expand resources.
With ArduMaker you can host the backend on a VPS, deploy from Git, configure an HTTPS domain, and use database, service, and MCP tools according to the project. This makes it easier to bring operations together in one environment, although business rules and security remain the responsibility of the software.
What I would measure to know if it improved
I would not measure only "works/does not work." I would also review resource consumption, errors, response times, or API usage, depending on the functionality. Define a success metric before the change and compare it with the same scenario afterward.
If a piece of data seems strange, check the sample and the time window. An average can hide extreme cases, and a single successful execution does not prove that an automation can handle thousands of requests.
Frequently asked questions
Do I need a large infrastructure to get started? Not necessarily. First solve the problem with a simple architecture and measure the point where it starts to fall short.
What happens if the external provider fails? You need timeouts, a retry policy, and a useful response for the user. Do not assume external APIs are always available.
How do I maintain control? Log important events, separate permissions, and keep a tested procedure to undo changes or recover information.
References to follow
The final idea: automating and measuring is worth it when you also know how to detect an error, limit its effects, and recover.