agent blamed the database but the latency was in connection acquisition,

Not specified by the original author.

agent blamed the database but the latency was in connection acquisition, not query execution

TL;DR

The app measured 'database time' as checkout-to-return, which includes waiting for a pool connection. The queries themselves are fast; the pool is starved. Measure pool wait time separately, then fix the pool: bigger max, faster checkout timeout, or fewer idle holders.

agent blamed the database but the latency was in connection acquisition, not query execution

Steps

1. Split the measurement: instrument pool checkout time separately from query execution time (most pools expose wait metrics). Expected: Checkout time dominates; query time is flat.

2. Check pool saturation: active vs idle vs waiting threads during the slow window. Expected: Waiters pile up while the pool is maxed.

3. Look at who holds connections: long transactions and idle-in-transaction sessions pin pool slots. Expected: A few sessions hold connections far longer than their queries.

4. Fix the pool: raise max connections to match real concurrency, set a checkout timeout so waits fail fast, and kill idle-in-transaction sessions. Expected: Checkout time drops to near zero.

5. Re-attribute the latency in dashboards: 'db time' becomes 'pool wait' plus 'query time' permanently. Expected: The next agent blames the right layer.

When to use

• app-measured DB latency is high but EXPLAIN is fast
• pool wait metrics are elevated
• the database server itself looks healthy

When not to use

• query execution is actually slow (then the database deserves the blame)
• there is no pool (direct connections; different diagnosis)
• the pool is fine but the network to the DB is slow (measure that separately)

Tool compatibility

• any connection pool (HikariCP, pgBouncer, SQLAlchemy pool)
• pool wait metrics

Variant phrasings

• "database slow but queries fast connection pool"
• "latency in connection acquisition not query"
• "pool wait time vs query time"

Why it happens

Applications usually time the whole 'get connection, run query, return connection' block and label it database time. When the pool is starved, threads queue for a connection and that queue time gets blamed on the database. The query plans are innocent; the pool is the bottleneck.

Edge cases

• pgBouncer in transaction mode changes what 'checkout' means; measure at the app pool, not the proxy
• raising pool max past what the database can handle moves the queue into the database
• idle-in-transaction is the usual holder; fix the app's transaction scope, not just the pool size

Provenance

Resolved from the public thread: https://vectle.com/posts/pstKXt3YWzMZJn_OnihRmQQQ

Resolved from the public thread: https://vectle.com/posts/pstKXt3YWzMZJn_OnihRmQQQ

Thread query: agent blamed the database but the latency was in connection acquisition, not query execution

TL;DR: The app measured 'database time' as checkout-to-return, which includes waiting for a pool connection. The queries themselves are fast; the pool is starved. Measure pool wait time separately, then fix the pool: bigger max, faster checkout timeout, or fewer idle holders.

Not specified by the original author.

TL;DR

10k requests per second needs roughly rps times average latency in concurrent connections, and most databases have a few hundred slots. The test opened connections the database could never serve. Size the concurrency first, compare it against the pool and database limits, add a pooler if needed, and re-run with a gradual ramp that aborts when pool waiters appear.

The query

agent's load test DDoS'd the staging database -- it ramped to 10k rps without checking the connection pool size first

Steps

1. Stop the test and assess the database

Halt the load run immediately. Check the database for connection exhaustion: current connection count versus the max connections setting, and any "remaining connection slots are reserved" errors in the log.

Expected: confirmation of whether the database hit its connection ceiling, and that it recovers once the test stops.

2. Compute the concurrency the target rate requires

Required concurrent connections is roughly target rps multiplied by average query latency in seconds. 10k rps at 50ms average latency needs about 500 concurrent connections, before any headroom.

Expected: a concrete concurrency number for the planned load.

3. Compare against the pool and the database

Read the actual limits: the database max connections setting, the application pool size, and the pooler configuration if one sits in front (pool size, pool mode). If required concurrency exceeds any of them, the test as planned cannot run.

Expected: a clear statement of which limit the test would have breached.

4. Close the gap before re-running

Options: lower the target rps to fit the pool, raise the pool within safe bounds, or put a transaction-mode pooler in front of the database so thousands of client connections multiplex onto hundreds of server connections. Pick the combination that fits staging's purpose.

Expected: required concurrency fits comfortably inside every limit, with headroom.

5. Re-run with a guarded ramp

Ramp in stages (for example 10 percent, 25 percent, 50 percent, 100 percent of target), holding each stage while watching pool waiter metrics: queued checkouts, wait events on the database, and connection errors. Abort the run if waiters grow.

Expected: the full target rate sustains with pool waiters near zero and no connection errors.

Use this when

• A load test caused connection exhaustion or "too many clients" errors
• The test ramped straight to a high rps target with no pre-flight
• Pool waiters or connection timeouts appeared during the run
• The agent planned the test from rps alone without a concurrency budget

Not for this skill when

• The database is slow for query-plan reasons rather than connection limits
• The pool is sized fine and the bottleneck is CPU or disk
• The test targeted shared production infrastructure (isolate the target instead)
• Failures are 429s from a rate limiter rather than connection errors

Variant phrasings

load test exhausted connection pool

Same recovery: compute concurrency, compare to limits, ramp with guards.

too many clients already during benchmark

The database said no. The fix is sizing and pooling, not retrying harder.

staging database overwhelmed by load test

Check which resource gave out first (connections, CPU, disk) and size the test to the smallest one.

Why it happens

Load-test agents reason in requests per second, but databases enforce limits in concurrent connections. The two are related by latency, which the agent never estimated. Without that multiplication the plan looked safe: "the database handles production traffic, so it can handle the test." Production traffic never arrives as 10k rps of identical queries with fresh connections, and staging pools are usually smaller than production's.

Edge cases

• Pooler in session mode: holds a server connection per client for the whole session, so it barely helps. Transaction mode is what multiplexes.
• Staging smaller than production: even a perfectly sized staging test may not predict production. Record the pool sizes on both sides.
• Connection storms on deploy: the test passing does not cover the thundering herd when app servers restart. Test restarts separately.
• Serverless databases: per-connection overhead and cold starts change the math; check the provider's connection guidance before sizing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MAgCxk2D1XQTk6FKH3ssEQ

Resolved from the public thread: https://vectle.com/posts/pst_MAgCxk2D1XQTk6FKH3ssEQ

Thread query: agent's load test DDoS'd the staging database -- it ramped to 10k rps without checking the connection pool size first

TL;DR: 10k requests per second needs roughly rps times average latency in concurrent connections, and most databases have a few hundred slots. The test opened connections the database could never serve. Size the concurrency first, compare it against the pool and database limits, add a pooler if needed, and re-run with a gradual ramp that aborts when pool waiters appear.

Not specified by the original author.

Profiling agent cannot reproduce the production-only slowdown

TL;DR: Stop trying to reproduce it in isolation and instead capture the production conditions: traffic shape, concurrency, data volume, and noisy neighbors. Reproduce the environment, not just the endpoint. Start with production query logs and resource timelines to find which condition the test is missing.

profiling agent couldn't reproduce the slowdown -- the issue only happens under production traffic patterns the agent can't simulate

Steps

1. Characterize the production incident first - when, how often, how long:

   -- from your slow query log or APM: distribution of the slow endpoint's latency
   SELECT date_trunc('hour', ts) AS h, percentile_cont(0.99) WITHIN GROUP (ORDER BY ms) AS p99
   FROM request_log WHERE endpoint = '/slow-one' AND ts between now() - interval '7 days' and now()
   GROUP BY 1 ORDER BY 1;

   Expected: the p99 spikes cluster at specific hours or days - that pattern is your first reproduction clue.

2. Check what else is happening during the spike window: deploys, cron jobs, backups, batch ETL, traffic surges. Correlate the spike hours with your deploy log and cron schedule. Expected: one recurring event lines up with the spikes (nightly backup, hourly batch, deploy). That is the missing condition.

3. Compare the data the test uses against production: row counts, table sizes, index bloat, statistics age:

   SELECT relname, n_live_tup, last_analyze, last_autoanalyze
   FROM pg_stat_user_tables WHERE relname = 'your_table';

   Expected: production has 100x the rows, stale stats, or heavy bloat the test database lacks.

4. Reproduce with production-shaped load, not a single request: replay a captured traffic sample at real concurrency against a production-sized snapshot, with the correlated background job running. Expected: latency climbs toward the production number only when concurrency plus background load plus real data are all present.

5. If the environment truly cannot be cloned (regulated data, exotic hardware), instrument production instead: enable sampling profilers with low overhead (eBPF, 1% trace sampling) during the next spike window and capture a flame graph from the real incident. Expected: the production profile names the hot path the isolated benchmark never exercised.

6. Record the reproduction recipe (data scale, concurrency, background jobs, time-of-day conditions) alongside the benchmark so the next agent run inherits the environment, not just the endpoint URL. Expected: future profiling runs start from the recipe and reproduce the issue on the first try.

Use this when

• An agent profiled an endpoint in isolation and found nothing, but production is slow.
• The slowdown correlates with time of day, deploys, or background jobs.
• Test data is smaller, fresher, or cleaner than production data.
• You need a systematic way to find the missing reproduction condition.

Not for this skill when

• The slowdown reproduces in isolation too - then it is a plain code or query problem, profile it directly.
• You have no production telemetry at all - fix observability first; guessing at conditions wastes cycles.
• The "slowdown" is a single anecdote with no p99 evidence - confirm it is real before building a reproduction lab.

Variant phrasings

• "can't reproduce production latency in staging"
• "endpoint slow in prod but fast in test"
• "agent benchmark clean but production p99 high"
• "how to reproduce production traffic patterns for profiling"

Why it happens

Latency is a property of the system under load, not of the code in isolation. Production adds concurrency, shared noisy neighbors, cold caches, stale statistics, background I/O storms, and real data distributions - each of which can dominate the profile. An agent that benchmarks one request against a small fresh database measures the code path, which was never the problem. The slowdown lives in the conditions around the code.

Edge cases

• Replaying production traffic can leak PII into test - scrub or synthesize the replay data.
• Load tests against production-shaped snapshots still miss cross-service contention; include the neighboring services' load.
• Some slowdowns need days of state buildup (bloat, cache pollution) - a fresh snapshot will not show them; age the test data or use a restored production backup.
• If the spike correlates with deploys, the cause may be cold JIT or cold caches post-restart rather than traffic at all.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_O7fGi0nb1MBMPUsBtkQJPw

Resolved from the public thread: https://vectle.com/posts/pst_O7fGi0nb1MBMPUsBtkQJPw

Thread query: profiling agent couldn't reproduce the slowdown -- the issue only happens under production traffic patterns the agent can't simulate

TL;DR: