Spring Reactive微服务请求延迟排查：初始200ms耗时去向不明问题咨询

Hey there, let's break down where that initial 200ms delay (before your Service A's API is even hit) might be hiding. Since Service A is a Spring Reactive application, we'll cover both general infrastructure causes and reactive-stack-specific quirks:

1. Network/Infrastructure Layer Delays #

This is the most common starting point, as the delay occurs before the request reaches your service code:

• Load Balancer/Ingress Queueing: If you're using a load balancer (like Nginx, AWS ALB) or Kubernetes Ingress, requests might be waiting in a queue before being forwarded to Service A. Check your LB's access logs to compare the timestamp when the LB receives the request vs. when it sends it to Service A—look for gaps matching that 200ms window.
• TCP/TLS Handshake Overhead: If the client is establishing a new connection (instead of reusing a pooled one), the TCP three-way handshake + TLS handshake could add significant latency. Use curl -w "%{time_total}\n" to measure total client-to-service time, or Wireshark to capture traffic and analyze handshake durations.
• DNS Resolution: Rare but possible—if the client is resolving Service A's hostname for the first time, use dig or nslookup to measure resolution time and confirm it's not contributing to the delay.

2. Spring Reactive EventLoop Blocking/Queueing #

Spring WebFlux relies on Netty's EventLoop threads to handle incoming requests—if these threads are blocked or overwhelmed, requests will queue up:

• Check EventLoop Metrics: Use Micrometer to monitor metrics like netty.eventloop.queue.size and netty.eventloop.delay (if enabled). Spikes in queue size or delay values mean requests are waiting for available EventLoop threads.
• Detect Hidden Blocking Calls: Even if your controller returns a Mono, blocking calls in upstream components (like your userService) can block the EventLoop. Use async-profiler or jstack to capture thread dumps during the delay, and look for EventLoop threads stuck in blocking operations (e.g., java.net.SocketInputStream.read()).
• Adjust EventLoop Configuration: Ensure your Netty EventLoop has enough threads (default is CPU-core based). For high-concurrency workloads, tweak server.netty.worker-count in your application properties.

3. Pre-Request Filter/Interceptor Overhead #

Spring WebFlux runs global WebFilter beans before your controller is hit—these can introduce unexpected delays:

• Audit Filter Execution Time: Add timestamp logs at the start and end of each WebFilter to isolate slow filters. Common culprits include authentication filters (e.g., OAuth2 token validation calling an external auth server), heavy request logging, or custom filters with slow logic.
• Check Zipkin Span Breakdown: If your Zipkin setup traces filter-level spans, look for spans labeled with filter names that have durations matching the 200ms delay.

4. JVM Garbage Collection Pauses #

A sudden 200ms delay could be caused by a full GC or long young GC pause:

• Analyze GC Logs: Check Service A's GC logs for pause events aligned with the slow request's timestamp. Look for lines like Total time for which application threads were stopped: 201.3ms.
• Monitor GC Metrics: Use Micrometer or Prometheus to track jvm.gc.pause metrics, and correlate pause durations with your request latency data to confirm if GC is the culprit.

5. Lazy Initialization (For First-Time Requests) #

If this delay only happens on the first request after Service A starts up, it's likely due to lazy-loaded beans:

• Check Application Logs: Look for logs indicating bean initialization during the first request (e.g., Initializing bean 'userService'). Spring sometimes lazily initializes non-critical beans to speed up startup.
• Warm Up the Service: Add a post-deployment warm-up script that sends a few test requests to trigger bean initialization. Subsequent requests should then have no initial delay.

内容的提问来源于stack exchange，提问作者maverickabhi