A.8 Service Times

only for RuBoard - do not distribute or recompile

Table A-11 shows the mean and median service times for different types of requests . The type is taken directly from the fourth field of Squid's access.log file. The three-digit number following the slash is the HTTP status code. Here I show only 200 (OK) and 304 (Not Modified) replies.

Table A-11. Mean and Median Service Times by Cache Result (IRCache Data)

Type	Mean (sec)	Median (sec)
TCP_REFRESH_HIT/200	5.165	0.281
TCP_MISS/200	4.590	0.466
TCP_REFRESH_MISS/200	4.091	0.468
TCP_CLIENT_REFRESH_MISS/200	1.889	0.215
TCP_HIT/200	1.819	0.050
TCP_MISS/304	1.151	0.294
TCP_REFRESH_HIT/304	1.107	0.219
TCP_IMS_HIT/304	0.102	0.042

The string before the slash indicates how the cache handled the request. TCP_MISS means the object wasn't found in the cache at all. TCP_HIT indicates an unvalidated cache hit. TCP_IMS_HIT occurs when Squid receives an If-modified-since request and returns a 304 (Not Modified) reply immediately because the response is fresh according to the local configuration. TCP_CLIENT_REFRESH_MISS means that the user -agent sent the no-cache directive. TCP_REFRESH_HIT occurs when Squid validates its cached response and learns that the object hasn't changed. If the client's request includes an If-modified-since header, Squid returns the 304 message. Otherwise, it sends the entire object, and the status is 200. Finally, TCP_REFRESH_MISS means Squid sent a validation request to the origin server, and the cached object was out-of-date.

This data is derived from the second field of Squid's access.log . Squid records the elapsed time for each HTTP transaction. The timer starts when Squid accepts a new connection or when it reads the first byte of the request on a persistent connection. The timer stops when the connection is closed or when the last byte of the response is written on a persistent connection. Note that Squid's notion of service time is inaccurate for a couple of reasons:

The operating system buffers data as it is written out to the network. It accepts data from the application, typically up to 32KB, and then transmits it to the other end according to the TCP/IP protocols. Squid doesn't know when the client actually receives the final packet. This is especially significant for cache hits, most of which are smaller than 32KB. TCP packets may be delayed, dropped, and retransmitted without affecting the service time.
Similarly, when Squid closes a connection, the operating system takes care of the final handshake. The application doesn't know when the client receives the FIN packet that closes the connection.

Not too surprisingly, all the 200 (OK) status responses take longer than the 304 (Not Modified) responses. The 304 responses are smaller, consisting of HTTP headers only. Also, as we would expect, cache hits (except for TCP_REFRESH_HIT) are sent faster than cache misses. By comparing the mean and median values, we can conclude that the reply size distributions have heavy tails .

only for RuBoard - do not distribute or recompile