The API Is Not Slow. The Database Is.

Most "the API is slow" tickets are not API problems. They are database problems with an HTTP wrapper.

The API is usually the messenger. It receives the request, opens a connection, waits, and returns what the database gave it.

CPU is a poor first metric

When an endpoint slows down, CPU is the first number most teams look at, and it is often the least useful. A server can sit at low CPU while every request waits on a lock, a bad plan, or a saturated connection pool. Low CPU with high latency is not a healthy signal. It is a signal that the work is happening somewhere else.

What I look at

• SQL Server wait stats, not just CPU.
• Blocking and deadlocks.
• Actual execution plans and actual row counts.
• Parameter sniffing: the same query fast for one parameter and slow for another.
• Connection pool usage and connection lifetime.
• Timeouts and retries, because retries can turn a slow dependency into an outage.

Wait stats are the fastest way to find where the time goes. If the top wait is a lock, the problem is concurrency. If it is pageiolatch, the problem is reads and memory. If it is a network wait, the problem may not be the database at all. Each answer points at a different fix.

Plans, not queries

The query text is rarely the whole story. The plan tells you what the optimizer chose, and the actual row counts tell you whether that choice was reasonable. A plan built for ten rows and executed for two million is a different problem from a missing index, even though both look like a slow query.

Parameter sniffing is the classic version of this. The same statement is fast for one customer and slow for another because the cached plan was compiled for the wrong shape of data. The fix is a plan guide, a recompile hint, or a code change that removes the reuse. Guessing which one without the plan is how teams spend a week on the wrong fix.

The pool is part of the query

Connection pool exhaustion looks like a database problem and behaves like an application problem. Connections held longer than they should be, connections opened and never closed, and connection lifetime settings that fight the load balancer all show up as latency at the endpoint.

Retries make it worse. A slow dependency plus an automatic retry policy can multiply load at exactly the moment the system has the least capacity to absorb it.

The point is to measure before you tune. Guessing produces changes that cannot be verified, and unverifiable changes come back.

When an endpoint slows down, which metric do you check first?