Best Metric for Diagnosing Remote Office Web Page Delays?
Users in a remote office report that corporate web server pages are taking a long time to load, whereas users in the main corporate office do not have any issues. Which of the following is the best metric for a network administrator to check?
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Tests the ability to match symptom-based troubleshooting to the correct performance metric, with the common trap being confusing traffic volume analysis or physical error rates with actual transmission delay.
When remote users experience slow web access while local users remain unaffected, hop-by-hop network latency is the most effective metric to identify WAN path delays and routing inefficiencies. Community consensus confirms that measuring latency per hop directly isolates where bottlenecks occur along the extended network path.
Option D (Server NetFlow data) is frequently selected because it monitors traffic patterns, but it fails to quantify delay; candidates often mistake bandwidth utilization for latency when diagnosing application slowness.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Hop-by-hop latency directly measures the time packets spend traversing each network segment between the remote office and the corporate server. Network administrators typically use traceroute utilities to map these delays, revealing whether an ISP is routing traffic inefficiently or if a specific WAN link is experiencing congestion. Since only remote users are impacted, the bottleneck must exist on the wide-area path rather than within the local LAN or on the server itself.Why the Other Options Are Wrong
Jitter (A) measures the variation in packet delay over time, which primarily degrades real-time applications like VoIP and video conferencing rather than standard web browsing. CRC errors (C) indicate physical layer corruption or faulty cabling, which typically cause packet drops and TCP retransmissions instead of consistent high latency, and would not selectively affect only remote locations. NetFlow data (D) tracks traffic volume, protocol distribution, and flow statistics, making it valuable for capacity planning but useless for pinpointing transmission delays.Community Comment Notes
Multiple highly-rated comments emphasize running atracert command to visualize hop counts and latency spikes, confirming that unexpected route changes often signal improper ISP routing. One user clarifies that while NetFlow provides insights into traffic patterns, it does not inherently output latency metrics, reinforcing why option B remains the strictly correct choice. Another contributor notes that identifying the exact hop introducing delay allows administrators to escalate the issue to the appropriate service provider efficiently. Official Reference
Exam Strategy
Always isolate the affected scope before selecting a metric: compare remote vs. local symptoms to rule out LAN or server-side causes. Match the symptom directly to the measurement—use latency for slowness, jitter for real-time media quality, error counters for physical/link degradation, and flow data for traffic analysis.