Re: [squid-users] Squid approach to C10K problem

> Hi,
>
> Just out of curious, how does squid as a single threaded server, to
> handle massive amount of clients nowsday?
>
> http://www.kegel.com/c10k.html
>
> Especially some others (http://varnish.projects.linpro.no/) say squid
> is old fashion and don't honor those approach such as epoll/kqueue
> which is famous in handling many clients using minmount efforts.
>
> But I know it is not true, I have been using Squid for years and think
> squid is very efficient and fast enought to serve massive clients. So
> I want to know if any hidden secrete behind?
>
> What is you guy comments on those issues ( c10k/epool etc)
>
> Thank you.
>

(FYI: this is just my opinion here, not any other developers)

There really is no accurate direct comparison. varnish is a niche
reverse-proxy, Squid is a general caching proxy.

The varnish write-up about Squid appears to be based on the obsolete 2.5
or such. Squid has epoll/kqueue since 2.6 when built to enable them.
Squid-3.1 now operates in a fully async model which avoids event-driven
bottlenecks.

The fantastic new cache management system varnish goes on about being its
cornerstone has an almost exact equivalent in the Squid COSS directory,
which are extremely fast for small objects but not recommended for large
objects. (A problem often reported about varnish IME).

There are still some legacy design issues, but we are steadily working at
eliminating those on the way to full SMP and HTTP/1.1 support.

We don't exactly have high-end hardware to test on so aim mostly at
cracking the C1K/C5K problems for the low-end stuff we have, with hope
that it scales up towards 10K on faster hardware.

The C10K problem in a general proxy is hampered by network lag times to
remote servers and obfuscated sites causing <50% hit ratios. Varnish is
aimed at the reverse-proxy market where 80% hit ratio is considered bad.
For those setup Squid performance rises dramatically (about an order of
magnitude), though we don't have accurate benchmarks with current Squid to
use for direct comparison to anything.

In the last year I've seen graphs from a few Squid that are pushing
>50MB/sec at 40-50% hit ratio forward-proxy under 500 requests/sec. Are
you sure you want Squid to push C10K ;)

The closest thing to a 'trick' we have is 100% non-blocking code running
async on a 'greedy' CPU algorithm to get as much of each transaction
finished as possible before anything needs to be switched/paged for the
next transaction.

Amos
Received on Tue Mar 17 2009 - 00:07:18 MDT