Re: Does squid eat much of CPU?

David J Woolley wrote:

> This contradicts the recent statement that the use of persistent
> connection for client and server sides is independent, although it
> did seem to me that it must do multiple connections to the server.
> (The HTTP 1.1 guideline is no more than twice the number of users,
> presumably meaning browsers, not browser connections, in the ideal
> case.)

No, it doesnt. The connections are independent. Squid uses as many
server connections as needed to perform the workload assigned by the
client (browser), but the connections are shared between all clients on
an request per request basis. So if a client opens 4 connections to
Squid, sends requests on 3 of them, of which 1 is in the cache, then 2
server connections will be used. And as soon as one server connection is
done with one request it may be reused by another request (from the same
client, or another client).

> As I remember it, the guideline for browsers is to use no more than
> two connections when persistent connections are available (presumably
> one for the HTML and one for the images and other objects), but they
> are likely to start a connection per image, otherwise. (See section
> 8.1.4 of the HTTP 1.1 specification.) The result of this will tend
> to be that only one image is rendered at a time, which may make the
> page subjectively slower.

True. HTTP/1.1 recommends at most 2 persistent connections. Squid does
in no way enforce this guideline on browsers. The answer to your concern
on browser performance is pipelining of requests on these 2 connections.
There are very strong reasons at the TCP/IP level why this
recommendation exists. The goal of connection management in HTTP/1.1 is
to transform web browsing to a well behaving application according to
TCP/IP standards. TCP/IP is well suited for long lived connections, both
interactive and data intensive, but not well suited at all for short
lived connections like traditionally used in web browsing.

--
Henrik Nordstrom
Spare time Squid hacker