Identifying the Source of Network Delay

by Ed Tittel
Network delays can stem from a variety of sources, including server delay, device delay, and network latency.
Server delay falls into several categories. When a client request shows up at a server, it takes time for the incoming frame to make it to the target application, and additional time for the individual TCP segments to be reassembled into a complete utterance or for UDP packets to add up to something an application can use. This might be called protocol processing delay and represents the time needed to complete incoming information delivery to some application or service.
Then there’s processing delay, where the request waits its turn to be processed, and eventually gets processed. When the request generates a reply and the first part of that reply starts to leave the server, the server delay portion is considered to be over, even though the rest of the reply may take some time to leave the machine, enter the network, and travel to the client (at that point, the server processing is over and the rest is protocol mechanics).
Things get really interesting with multi-tiered applications, where a Web server might call on a database server or an e-commerce server in response to a user request or activity. Some multi-tiered applications can then spawn even more levels of server requests for access to transaction servers or back-end applications, so that a single client-server interaction might actually spawn half-a-dozen constituent server-to-server interactions in the background.
Because all of these things also contribute to the overall server delay observed between when the request arrives at the first server and when it starts to emit a response to that request, all these other tiers also play into the server delay component. Design issues related to workload, poor back-end communications design, or questionable error handling techniques can make substantial additions to overall server delay times.
Ed Tittel is the author of the Exam Cram series of computer trade books, and has written over 130 books in total.
We’ve covered this issue from a round-trip time perspective previously in “Bandwidth is not a Panacea“