How to Diagnose and Optimize API Latency with DevTools, httpstat, and Flame Graphs

Analyzing API latency involves splitting total response time into distinct parts to clearly understand the root causes of high latency, using various tools in different network environments to propose optimization suggestions.

Request sending too slowly increases latency;

DNS resolution too slow increases latency;

Poor network conditions increase latency;

Queueing causes slow response;

Server response too slow increases latency;

Large response body increases latency;

Other factors…

Many people assume a slow API is always due to "server processing slow", but comparing internal‑network and external‑network API timing often reveals the real reasons.

Analyzing with Browser Developer Tools

Key metric: Waiting (TTFB) – time until the first byte arrives, including round‑trip latency and server preparation time, roughly representing server‑side latency.

If the network is bad or the response is large, Content Download will take longer, suggesting compression.

Timing Details

In the DevTools Network tab, each resource shows a Timing breakdown: Queueing: request is queued due to higher‑priority requests, TCP connection limits (six per host for HTTP/1.0 and HTTP/1.1), or temporary disk cache allocation. Stalled: request paused for any reason described in Queueing. Proxy negotiation: browser negotiating with a proxy server. Request sent: request is being sent. Waiting (TTFB): waiting for the first byte of the response. Content Download: receiving the response body.

Other Possible Phases

DNS Lookup

: resolving the request's IP address. Initial connection: establishing the connection, including TCP handshake and SSL negotiation.

Analyzing with httpstat Tool

Git repository: https://github.com/reorx/httpstat

Installation options:

Download script:

wget https://raw.githubusercontent.com/reorx/httpstat/master/httpstat.py

Via pip: pip install httpstat On macOS with Homebrew:

brew install httpstat

Usage Example

httpstat www.baidu.com httpstat 127.0.0.1/post -X POST --data-urlencode "id=1" -v

The Server Processing field approximates server‑side time.

Where Is the Server Slow?

Printing Timing Logs

StopWatch stopWatch = new StopWatch();
stopWatch.start();
// ...
stopWatch.stop();
LOGGER.info("[Business] - [Time:{}ms]", stopWatch.getLastTaskTimeMillis());

Simple but may require many logs if not targeted.

Using Flame Graphs

Flame graphs visualize program execution and are powerful for performance analysis and debugging.

Popular tools include Async Profiler and linux‑perf; IntelliJ IDEA also integrates Async Profiler.

IntelliJ IDEA Flame Graph

Select a running Java process to generate a flame graph.

Using Async Profiler Directly

Git address: https://github.com/jvm-profiling-tools/async-profiler

Installation: download the archive, unzip, and use the provided scripts.

./profiler.sh -d 10 -f /tmp/flamegraph.svg <pid>
./profiler.sh -e itimer -d 10 -f /tmp/flamegraph.svg <pid>

Options: cpu: collect stack samples including Java, native, JVM, and kernel frames. alloc: collect allocation hotspots instead of CPU usage. lock: profile lock contention (Java monitors and ReentrantLock). wall: sample all threads regardless of state, useful for startup time analysis. -e <event>: specify events such as cpu, alloc, lock, wall, itimer. ClassName.methodName: focus profiling on a specific Java method.

Open the generated flamegraph.svg in a browser and locate the API call (e.g., ProjectManageController.findProject) to see which internal calls dominate the latency.

If method names are stripped, add -XX:+PreserveFramePointer to the JVM startup options.

Doing More Work

Improving user experience is a long‑term effort; beyond basic metrics, custom user‑centric metrics such as Server‑Timing can be defined to better measure performance.