Re: Benchmarking Squid

On Tue, 2008-04-29 at 22:58 +0800, Adrian Chadd wrote:
> On Tue, Apr 29, 2008, Alex Rousskov wrote:
>
> > > Don't forget other key things which affect scalability, such as concurrent
> > > connection count and memory usage.
> >
> > The number of active concurrent connections is just request rate
> > multiplied by response time. The number of idle persistent connections
> > can be a metric.
>
> Think in terms of "large file transfers" rather than in terms of small
> transfers over potentially persistent connections.

The size of transfers does not matter. The laws of physics apply to all
of them :-).

> Request rate includes parsing overhead, forwarding overhead, etc.
> Existing connections don't include parsing and forwarding overhead
> (they're done!), but include overheads in passing data through various
> layers, scheduling callbacks, the amount of memory being kept that
> may or may not be used, etc.
>
> So yes, the number of concurrent connections is request rate * response
> time * fudge; but the amount of CPU used for request rate versus active
> versus idle connections isn't quite as simple.

IIRC, I did not say anything about the CPU usage and its "simple"
relation to the request rate or the number of concurrent connections. It
obviously is nothing but simple.

My point was that the number of active concurrent connections is not a
primary/key metric because it is just a product of two other primary
metrics. You cannot, for example, freeze request rate and response time
and then optimize the number of concurrent active connections. I have
seen numerous cases where testers were wasting time because they did not
understand this relationship, and that is why I decided it could be
important to bring this to Amos attention in case he is working on some
guidelines or result reporting templates.

The number of idle persistent connections is a different story. It can
be an important knob/measurement even though it is often ignored.

Cheers,

Alex.
Received on Tue Apr 29 2008 - 15:44:13 MDT