Re: [squid-users] cpu profiling

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 06 Mar 2013 11:42:23 +1300

On 6/03/2013 5:57 a.m., jiluspo wrote:
> Good day,
>
> I was hoping where I could find users/developers squid's CPU
> profiling and benchmarks was published. I'd like to know where squid is more
> hungrier.
>
> I did some test which kind of unclear for me to get conclusion. Currently at
> connection established vs request/sec.

Hi jipespo,
  You are asking two things..

service metrics:

   The HTTP statelessness and keep-alive features mean that req/sec
should be many, many times larger than connections/sec established.
There is no limit to the number of transactions performed on one
connection. The whole connections vs req/sec varies from second to
second depending on what the traffic behaviour is.

The most accurate, reliable metrics in this area are:
  req/sec completed - for total proxy service capacity
  connections/sec opened - for new-client service response times. This
will be capped somewhere by TCP port and socket availability.

We have a collection of submissions at
http://wiki.squid-cache.org/KnowledgeBase/Benchmarks. But this does not
include any connection established information.

CPU profiling:

Depends a lot on the traffic load and VERY much on the configuration. We
(the squid dev team and various others) have made some attempts on and
off to get a usable corpus of documentation - but have not yet succeeded
in creating anything close to generically usable.

Web Polygraph is used for seed testing, but other than some req/sec
metric we don't record much out of it.

There is a profiler built into Squid that traces function usage.
  - It does not work very well and crashes on multi-threaded components
like AUFS. The fix got shunted down my TODO list.

oprofile and strace tools can get a detailed analysis of Squid library
usage.
  - AFAIK, both of these only measure the amount of work offloaded into
kernel or system libraries. So they won't give you much on what Squid
was doing internally.

Amos
Received on Tue Mar 05 2013 - 22:42:35 MST

This archive was generated by hypermail 2.2.0 : Wed Mar 06 2013 - 12:00:04 MST