Re: Performance question

Hi,

A thread close to my own heart. We currently run a cluster of 18 servers
running Squid 2.x under Linux to deliver 40 - 45Mbps downstream. There's
some spare capacity but we expect the bandwidth to double in the next 6
months and double again in the following year. The thoughts of managing 72
servers is pretty scary.

After the bakeoff I couldn't ignore Peregrine (the claimed throughput
suggesting a single server would cope with our current load). So far I
haven't managed to get Peregrine to perform anywhere near the levels quoted
in the bakeoff report, but even so it is delivering four times the
throughput of Squid on identical hardware.

As a test of Squid's potential I configured it to not cache anything to
disk and set it up to use the Peregrine proxy as a parent. Lo and behold,
Squid could more than saturate Peregrine, and this is using real request
patterns in a live network.

I think everyone realises that Squid's achilles heal is the fact that it
relies on the undelying OS to manage disk files. While the tests I've done
are admittedly not very scientific, they do suggest that effort spent on
the rumoured Squid-FS (or similar) would be worthwhile. A proxy with the
features and code maturity of Squid combined with the performance of
Peregrine would be a dream come true.

I wouldn't feel happy about using Peregrine in a production environment
today. Features are being added at a frightening pace and experience
suggests there are still a whole bunch of bugs to be shaken out.

Regards,
Simon.

>> So, considering this, why should I even consider squid?
>
>1) Many people do not need performance above 100 req/sec
>2) You can cluster several Squids to do more req/sec for less price
>3) Squid has lots of features no other proxy has
>4) Squid has better support than any other proxy has
>
>> Why shouldn't I just use peregrine?
>
>Because you should read Peregrine's README file first, including the
>"Status of Feature Implementation" section. You should also understand that
>even given Pei's very talented team and superior software language, the
>number of software bugs is reciprocal to the number of software users. You
>should consider Peregrine, but not "just use" it.
>
>Personally, I am very happy for Pei and her team. They are developing a
>very interesting cache, and I hope they will succeed. Peregrine is probably
>not ready for full-scale production use yet, but it had a very promising
>start.
>
>> The bakeoff had them, with a similar machine to the one I'm
>> considering, at 150+ reqs/s.
>
>Performance is not the only factor to consider. For example, the bake-off
>version of Peregrine did not have persistent (through failures) store. It
>is fixed in the current version, but the example illustrates my point.
>
>> This level of service is what I'm looking for, but I want free :> Squid
>> and peregrine seem to be my only choices, and the numbers on peregrine
>> look better. So what is it that I get when I go with squid that I don't
>> get when I go with Peregrine? And likewise, how is it that some class
>> project is better than something that has been worked on by several people
>> for several years?
>
>Peregrine is not a class project and had an advantage on using hundreds of
>tips and tricks from Squid source code. Also, Squid performance side used
>to be an underground project for several years. There are many reasons why
>Peregrine _performs_ better on _some_ workloads. If you consider all the
>factors, you will beta-test Peregrine and production-run Squid. By the time
>you are done with beta testing Peregrine, Squid will catch up on the
>performance side, and Peregrine might go commercial...
>
>> Not trying to bust anybody's balls, just curious.
>
>I gave you pretty obvious reasons. I am sure you can understand the other
>factors if you dig a bit deeper than the two numbers on a bake-off report.
>As for balls busting factor, you are somewhat safer with Peregrine's team.
>
>$0.02,
>
>Alex.

-------------------------------------------------------------------------
Simon Rainey Direct Line: 01235 823238
Principal Internet Consultant Fax: 01235 823424
RM Internet for Learning E-mail: srainey@rmplc.net
New Mill House, 183 Milton Park, Abingdon, Oxfordshire, OX14 4SE, England
Received on Tue Jun 15 1999 - 02:39:31 MDT