MSDN Magazine - November 2008 - (Page 75)

7). Then 2914ms (2.9 seconds) later the client resent the request (frame 306 in the figure) since it did not get a re1) 1483 www.goo-net.com sponse from the server. After the second request, the server 2) 1484 www.goo-net.com did respond 110ms later (frame 307). 3) 1485 www.goo-net.com It is interesting to note that retransmissions of TCP connect packets happen on an exponential back-off basis while 4) 1486 www.goo-net.com data packets within the connection are fast retransmitted. 5) 1487 www.goo-net.com So, failed connections will often take two or more seconds 6) 1488 www.goo-net.com for the first retransmission while data packets might only see a few hundred milliseconds to timeout. 7) 1489 www.goo-net.com 6. increase Network Max transmit Unit (MtU) or 8) 1490 www.goo-net.com tCp Windows Size Packet sizes can be as large as 1,514 9) 1491 www.goo-net.com bytes over ethernet. Sometimes servers may have the MTU (the size of the packets) limited to smaller sizes. If you see 10) 1493 www.goo-net.com large files with response packets significantly less than 1,500 11) 1494 www.goo-net.com bytes, then you should check this. Another related issue is the TCP window size. Normally 12) 1495 www.goo-net.com this is 16 or 32KB, depending on the OS. That means that 13) 1496 www.goo-net.com TCP can increase the number of bytes it sends before hav14) 1497 www.goo-net.com ing to wait for an acknowledgment. You can think of this as the number of bytes per round-trip, though that is an over simplification. TCP/HTTP usually starts out by sending 2 4 Seconds a window of two packets in the first response, about 3KB Kbps of data. Then the server waits for an acknowledgment be1015 fore sending another window. The window increases in size with each successful acknowledgment received. This 812 2 allows TCP to judge how much bandwidth is available be520 Kbps 609 tween the two devices. 406 Look for window sizes of less than 16KB coming from a server for extended periods, then change these back to the 203 default. To find the window size, open NetMon and look at Seconds 2 4 the “window size” of the server response packets. 7. identify Server Congestion A slow server often shows Figure 6 Keep-Alives up with a fast TCP connect time, a fast acknowledgment re4. turn on Keep-Alives Opening a TCP port uses one round- sponse at the TCP level, and then a slow Time-To-First-Byte data trip, and getting a file uses at least one round-trip. If you can keep response packet. Think of the server as operating in layers (as in the connection open for additional files, you’ll reduce the number the Open System Interconnection, or OSI, model), each working of round-trips and increase the effective throughput. Note in Figure 6 that there is only one port per TCP connection (the grey horizontal lines). The bit rate jumps only TCP connect rqst on the larger files. You can see inside of each file rectangle TCP connect rqst Retransmitted TCP connected the step pattern from increasing response volume. TCP Ack Get http://autograph This is TCP’s slow start algorithm ramping up, sending Response 200-OK more bytes per successful round-trip. That’s how larger files Figure 7 Time between Packets can send at faster rates. Reusing a TCP connection allows TTFB subsequent files to continue with the expanded window size instead of starting over. Keep-Alives are on by default in IIS and unless you TCP are hosting only a single file, they should always be left on. 5. identify Network Congestion It’s important to differentiTCP connect rqst ate between server and network delays. Network delays can often TCP connected TCP Ack be seen by looking at the TCP connect time or by looking for reGet http://website.com Get Continuation TCPAck from server transmissions. In the delta column of Figure 7 you see the time TCP Ack from server Response Data from server (Slow TTFB) between packets (in milliseconds). The TCP request to open a connection was the first packet sent by the client (frame 67 in Figure Figure 8 Slow Server Client Ports Domain msdnmagazine.com November 2008 75 http://www.msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.