5V0-43.21 · Question #43
An operator is troubleshooting reported performance problems for an HTTP Virtual Service and notices that the Server RTT in the End-to-End timing graph has recently increased significantly while…
The correct answer is C. One or more pool servers are experiencing very high CPU utilization. Option C is correct because Server RTT in Avi Networks (NSX ALB) measures the TCP-level round-trip time between the Service Engine (SE) and the pool servers. When pool servers are under very high CPU load, their network stacks become sluggish and delay TCP ACK processing - this…
Question
An operator is troubleshooting reported performance problems for an HTTP Virtual Service and notices that the Server RTT in the End-to-End timing graph has recently increased significantly while Client RTT and App Response times have remained unchanged. What can the operator deduce is the most likely explanation for the reported performance problems?
Options
- AA database server used by the application is experiencing a performance issue.
- BThe Service Engine where the Virtual Service is placed has become overloaded.
- COne or more pool servers are experiencing very high CPU utilization.
- DA networking issue has developed between the Service Engine and one or more pool servers.
How the community answered
(47 responses)- A9% (4)
- B6% (3)
- C62% (29)
- D23% (11)
Explanation
Option C is correct because Server RTT in Avi Networks (NSX ALB) measures the TCP-level round-trip time between the Service Engine (SE) and the pool servers. When pool servers are under very high CPU load, their network stacks become sluggish and delay TCP ACK processing - this inflates Server RTT. Crucially, App Response Time remains unchanged because the servers are still completing HTTP transactions in normal time; the bottleneck is in the lower-level TCP signaling, not application logic.
Why the distractors are wrong:
- A (database issue) - A slow database would delay the application's ability to generate responses, which would show up as increased App Response Time, not Server RTT.
- B (SE overloaded) - An overloaded Service Engine would degrade its ability to handle both client-side and server-side connections, so Client RTT would also increase, not just Server RTT.
- D (network issue between SE and pool servers) - While a network problem would also raise Server RTT, it would typically manifest alongside packet loss, retransmissions, and connection failures. High CPU on pool servers is the more specific and common cause of isolated Server RTT spikes without those additional network-layer symptoms.
Memory tip: Think of Server RTT as a "health ping" from the SE to the pool servers. A busy (high-CPU) server is slow to answer even simple TCP knocks, raising RTT - just like a person who's overwhelmed takes longer to even say "hold on" before they can actually help you.
Topics
Community Discussion
No community discussion yet for this question.