Re: [squid-users] tuning squid 2.3/2.4 on a slow connection

Actually, there is more to it than that. Squid has two known primary
bottlenecks at this point, as well as a few inefficiencies in other
areas. The small inefficiencies are slowly being addressed as people
rewrite and clean up sections of code (Henrik, Adrian, Robert, Andres,
Kevin, and some others who I'm probably regretfully forgetting are all
chipping in here with lots of cool work).

You are right about disk i/o. It is a significant bottleneck in Squid.
  However, I believe the more important work that Adrian is doing here
is the SFS stuff he is doing with Kevin and the COSS stuff that I think
he is tackling alone currently. IFS will be a nice thing for FreeBSD
users, but we've found (with the ReiserFS-raw interface) that just
taking the namespace and such out of the circuit and tuning the VFS
layer for Squid usage patterns does not suddenly make Squid fly. It
gives us about a 10-15% gain. That's a nice thing, but not a complete
solution. SFS and COSS will provide entire filesystem overlays designed
for Squid specific workloads. I suspect COSS or some future dirivative
will be the filesystem that leads us to the I/O efficiency we all desire.

Disk i/o is definitely not the only issue, however. Myself and others
have done benchmarks where disk i/o does not play a role (i.e. a small
enough benchmark working set to fit entirely in RAM--and disk i/o
disabled in Squid). Even with everything pulling from RAM (can't get
any faster than that!) Squid still maxes out at 300-500 reqs/sec, with
total dependence on CPU to make the difference between 300 reqs/sec (a
500 MHz CPU) and 500 (a 900MHz CPU).

The problem here is the network I/O. Currently this has two failings on
modern hardware. First, it uses a poll/select loop, which is quite
efficient with small numbers of clients, but when given thousands of
clients to deal with begins to eat up the CPU pretty badly. Poll/select
were the pinnacle of non-blocking network i/o design back when Squid was
new, and certainly can't be called a design 'flaw'...just an outgrown
technique. Second, Squid is single process by design...even when
compiled with async i/o or DiskD only disk accesses have extra worker
threads/processes to handle the i/o to disk. The network layer is still
bound to one CPU and directly limited by the throughput of a single CPU.
  Henrik is working on an event i/o network layer in the sourceforge
CVS, which will eliminate or reduce the impact of the first problem.
The second problem will have to be addressed by a multi-process
mechanism with shared memory for the object store swap.state (or a move
to a non-core swap.state, or a state-free design like the storetree from
Reiser-raw). Henrik has some good ideas here I think, and I suppose if
we're lucky, he'll have time to implement them eventually.

All that being said, I reserve the right to be wrong, and I hope that
Henrik or Adrian will correct me if I am misleading, or provide updates
if I'm unaware of significant advances in any of the areas I mention.

fooler wrote

>
> no matter how you tweak and optimize the same old architecture of a given OS,
> still squid req/sec throughput will not significantly increase. squid bottleneck
> is the disk i/o and you have to develop a new technique/algorithm to improve
> disk i/o. adrian did the right thing to improve disk i/o performance, he is
> working right now with his IFS. i believe this will significantly increase the
> req/sec throughput of squid.
>
> for more info about his latest work, click this url:
> http://people.freebsd.org/~adrian/ifs/
>
> oh btw adrian, when is the tentative date to release your IFS? :->
>
> fooler.

                                   --
                      Joe Cooper <joe@swelltech.com>
                  Affordable Web Caching Proxy Appliances
                         http://www.swelltech.com
Received on Sun Apr 08 2001 - 21:23:39 MDT