On Fri, 5 Dec 1997, Henrik Nordstrom wrote:
> Not entirely true. TCP_NODELAY does not disable the buffer, it only
> disable one possible delay.
Yes, you are right. If the inbound network is slow, TCP_NODELAY, I guess,
may not make any significant difference. The original observation still
holds though: TCP socket buffer helps hits a lot and does not help misses
much. Consequently, one should probably set it to 64K max if memory allows.
It could be interesting if one could try to use different buffer sizes for
hits and misses ("move" memory to hit connections where it pays off).
However, it is not possible on Squid's level, is it?
> And how did you measure? You can't measure the latency based on how fast
> Squid can process a request since the buffer will swallow any request up
> to buffer size regardless if it is delivered or not.
I do not measure the proxy->client latency. I measure the time it takes
_Squid_ to get rid of an object. I understand that an object could be
buffered on the way through the TCP stack. It does not look like it is
just _copying_ though: the delays are much bigger.
I was interested in those delays because they determine, in part, how many
concurrent connections Squid has to support, the number of network FDs,
etc. These delays are not what clients see, of course, but they are
important for Squid performance analysis. (Same thing with measuring disk
transfers on Squid's level: one cannot be sure it comes from/to disk
rather than from/to file system buffer).
Alex.
Received on Thu Dec 04 1997 - 19:57:27 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:37:51 MST