Would provisioned concurrency solve this Lambda latency problem?

Instruction: In a fictional trace, initialization takes 80 ms and the handler takes 2,000 ms, including 1,900 ms waiting on a database. Warm invocations have similar handler latency. Identify the main bottleneck and propose a measurement-led response.

Context: Assesses attribution of latency to initialization, handler work and downstream services rather than applying cold-start mitigations to every slow invocation.

Updated

Worked answer

The supplied cold request spends 2,080 ms in initialization plus handler execution. Initialization contributes about 3.85% of that measured time; the database wait dominates. Even removing all 80 ms would leave roughly 2,000 ms before any unmeasured gateway or network overhead. Warm requests being similarly slow supports investigating the handler/dependency path first.

Inspect the database operation and connection-acquisition spans, slow-query evidence, connection-pool pressure and concurrent load. Confirm that the timing boundaries are comparable and do not double-count nested spans. A CPU or memory change might help some workloads, but it does not establish a fix for this measured wait.

Compare representative cold and warm latency distributions, errors and database load after a proposed change. Keep startup optimizations as a separate experiment. Provisioned concurrency may still be worthwhile if the remaining startup tail violates a latency target, but it does not remove a slow database operation.

Source

Lambda initialization and execution lifecycle. The timing values are fictional practice inputs.

Related Questions