--- title: "Discussion on \"The API Wasn't Slow: Finding a 2-Minute Delay in the Delivery Path\" | Hashnode" description: "Discussion on \"The API Wasn't Slow: Finding a 2-Minute Delay in the Delivery Path\". The API requests took 2+ minutes. How Nginx timing logs and testing from multiple places revealed the delivery path bottleneck." url: "https://hashnode.com/posts/the-api-wasn-t-slow-finding-a-2-minute-delay-in-the-delivery-path/6af0c4620ba174b457f411ff" --- [Feed](https://hashnode.com/feed) / Discussion # [The API Wasn't Slow: Finding a 2-Minute Delay in the Delivery Path](https://codeincontextbyag.hashnode.dev/the-api-wasn-t-slow-finding-a-2-minute-delay-in-the-delivery-path?utm_source=hashnode&utm_medium=feed) The API requests took 2+ minutes. How Nginx timing logs and testing from multiple places revealed the delivery path bottleneck. 1d ago · 6 min read · codeincontextbyag.hashnode.dev Read the article - [#nginx](https://hashnode.com/tag/nginx) - [#debugging](https://hashnode.com/tag/debugging) - [#backend](https://hashnode.com/tag/backend) - [#performance](https://hashnode.com/tag/performance) - [#devops](https://hashnode.com/tag/devops) - [#api](https://hashnode.com/tag/api) - [#vpn](https://hashnode.com/tag/vpn) ## Written by [Akshita Gupta](https://hashnode.com/@codeincontext) @codeincontext · Delhi, India [View profile](https://hashnode.com/@codeincontext) Software Developer Production incidents, debugging & backend lessons, explained simply. ## Responses 7 Markdown supported · ⌘↵ to post [OneLifeVibe](https://hashnode.com/@onelifevibe) [1d ago](https://hashnode.com/posts/the-api-wasn-t-slow-finding-a-2-minute-delay-in-the-delivery-path/6af0c4620ba174b457f411ff/comment/6af19534bcff827a3c7a9b85) The Nginx timing split is the part I would steal for every team: upstream response time under 300 ms against a total request time of almost 80 seconds makes it obvious the API never had the problem, and once both numbers are logged side by side, every future "slow API" report becomes a one-line check. One suspect I would add weight to is the load generator itself — when the generator runs short on CPU or bandwidth, the failure pattern looks exactly like a flaky network, and one in three requests failing rather than all of them slowing down fits that shape. Did you get a chance to check the generator's own resource usage while the test was running? [Akshita Gupta](https://hashnode.com/@codeincontext) [21h ago](https://hashnode.com/posts/the-api-wasn-t-slow-finding-a-2-minute-delay-in-the-delivery-path/6af0c4620ba174b457f411ff/comment/6af19534bcff827a3c7a9b85#reply-6af1f034c7d67eee8348faab) Thanks! Logging both timings side by side is the habit I’d recommend most. The generator is a fair suspect, and the 1-in-3 failure pattern does fit that. \[I did check it during the run and CPU/memory were fine, so it pointed back to the path.\] Thanks for flagging. [Rishabh Mishra](https://hashnode.com/@rushdeploy) [1d ago](https://hashnode.com/posts/the-api-wasn-t-slow-finding-a-2-minute-delay-in-the-delivery-path/6af0c4620ba174b457f411ff/comment/6af13773359e94320fd69f44) The outside-vs-server replay is the cleanest part of this diagnosis. If the VPN is the suspect, I would run iperf3 across the tunnel during a load test and compare response size times requests per second with what the tunnel can actually carry. That usually separates a bandwidth limit from an MTU problem quickly. [Akshita Gupta](https://hashnode.com/@codeincontext) [21h ago](https://hashnode.com/posts/the-api-wasn-t-slow-finding-a-2-minute-delay-in-the-delivery-path/6af0c4620ba174b457f411ff/comment/6af13773359e94320fd69f44#reply-6af1f1f75bc4e54b52cb8138) Thanks Rishabh. That’s the next step I’d take too. Comparing the data the test pushes per second with what the tunnel can actually carry should separate a bandwidth limit from an MTU problem. \[If you’ve done this before, I’d like to hear what numbers you usually see.\] [Rishabh Mishra](https://hashnode.com/@rushdeploy) [10h ago](https://hashnode.com/posts/the-api-wasn-t-slow-finding-a-2-minute-delay-in-the-delivery-path/6af0c4620ba174b457f411ff/comment/6af13773359e94320fd69f44#reply-6af287bc3f082ff44067a12d) I don't use one fixed number, since it depends on the VPS and VPN type. I compare iperf3 throughput with the test's required throughput: if iperf3 is lower, it looks like bandwidth, and if iperf3 is high but large packets stall, I lower MTU toward 1400 and retest. [AI Developer](https://hashnode.com/@lycore) [1d ago](https://hashnode.com/posts/the-api-wasn-t-slow-finding-a-2-minute-delay-in-the-delivery-path/6af0c4620ba174b457f411ff/comment/6af12a2c4c646a52bf80c966) The outside-vs-server replay is a clean way to narrow the fault domain, and comparing Nginx upstream time with total request time makes the mismatch concrete. One nuance: request\_time minus upstream\_response\_time is not necessarily just response delivery; it can also include receiving the request body and proxy queueing. Logging request\_length and body\_bytes\_sent alongside the timings could help distinguish a slow upload from a slow response path. Did response size vary across the failing runs? [Akshita Gupta](https://hashnode.com/@codeincontext) [20h ago](https://hashnode.com/posts/the-api-wasn-t-slow-finding-a-2-minute-delay-in-the-delivery-path/6af0c4620ba174b457f411ff/comment/6af12a2c4c646a52bf80c966#reply-6af1f6408ea4ab53bd91b3e8) Agreed, the gap isn’t only delivery. It can include request upload and queueing too. I’ve fixed the wording in the post and added request\_length and body\_bytes\_sent to the log format. Thanks for pointing it out. On response size: \[it was about the same across failing runs / I didn’t track it, will log it next time\].