Re: [squid-users] fourth cache off??

khiz code wrote:

> Hi all
> i just went thru the fourth cacheoff results.. and straight away looked at
> joe's entry!!!
> i think it did particularly good on the hit response times and downtime tests
> however the requests/sec and the hit ratios were not exactly exciting :(
> and i did read joe's comment ..

Yep. I too was disappointed in the hit ratio. I'll be submitting a
patch or two pretty soon to make the load shedding a little less
aggressive so hit rates don't suffer so badly as request rates climb.
I've just been busy lately with updating our clients to Squid 2.4STABLE3
and lots of new management tools.

Anyway, Squid has never been the highest throughput option available,
but it is actually quite similar to Kotetu on equal hardware (the Kotetu
entry had 6 SCSI disks--we can definitely pull 200reqs/sec from 6
disks). Most of the other entries this time were iMimic based systems,
and generally iMimic is about the fastest on the market, making Squid
look a little less competitive than it really is in the market as a
whole. iMimic has done some remarkable work on performance issues, and
I hear from one of their OEMs that they've also come a long way on
getting many of the features of Squid. So for a proprietary solution,
it probably isn't a bad choice at all, but I have no direct experience
with it.

> is this due to the fact that he used only 2 scsi disks and the not yet stable
> released 2.5 ???? on kernel 2.4.13

Actually, the disks were 7200 RPM IDE disks. Kernel 2.4.13 hurt things
a bit as well, because of the VM layer in that version is so badly
broken for Squid-type workloads. It was an AC kernel, which kept the
old 2.4 VM until 2.4.13--and it has a pretty bad tendency to swap things
at the worst possible time, even with 2GB of RAM. I suspect part of the
hit ratio drop was due to swapping (yep, the kernel actually moved a
bunch of stuff into and out of swap during at least a couple of the runs
with over a GB of free memory available, don't ask me to explain why it
would do that). Our hardware was our new server platform, which
includes pretty new chipsets that haven't always been extremely well
support under Linux, so I was leary of jumping to a new untested kernel
for the test.

Interestingly, we weren't pushing the disks very hard at all. The
activity lights barely flashed even at peak throughput. So there is
plenty of room for improvement of hit ratio without lowering request
rate (and in fact the reason for running at 130 rather than 150 or so is
that hit ratio dropped so low in my pre-cacheoff tests, that I made the
trade off to go slower and raise the hit ratio by a few percent).

I started playing with the disk selection stuff just before the event
began, but didn't have enough time to even begin to test any changes, so
just ran with the current HEAD version.

I've also borrowed an idea from Brian here on the list a couple months
back for 'picky-writes', which when combined with a lot of RAM can
really reduce the disk write activity while not affecting hit ratio too
much. I'll get those patches into Squid as soon as I've had time to
make sure they work as advertised.

> Good work and brave heart Joe ,,, best of luck

Hehehe.. You act as if I've come out on the bad end of a fist fight.
;-) Don't worry, Khiz, Swell won't be losing any clients because of
these results--even if folks see the results and come to us for a quote
last. We've got the lowest cost ISP-ready rackmountable web caches on
the market (try to buy a box from any of our competitors for under $2k
that has no per-user limits and supports more than two T1 links--and
even better, is well supported and warrantied), and the happiest bunch
of clients at all levels you'll find. Not to mention offering the best
hardware for running an all Open Source caching solution. The buying
decision is almost never just about raw performance numbers (and it
would be rather stupid for someone to make a decision just on performance).

But I'll stop now because this isn't an advertising forum.

Oh, yeah, many will recall Vivek from iMimic pointing out here that
Squid had a long hit response time at previous events--he and I had a
little debate about it...It's worth noting the results this time. If
hit response time is the metric to look at, as Vivek suggests, Squid was
number four in the pack this time with a very respectable .025 response
time. I argued for looking at overall response improvement (which leads
to favoring caches with a higher hit ratio), which Squid did quite
poorly at this time due to the low hit ratio. As I think Vivek and I
both agreed, it really comes down to how hard the various components of
the system are being pushed when deciding what the response time will
be...and I think Vivek will now agree, that Squid /can/ provide
excellent hit response times when it isn't being pushed too hard.

BTW-There was some discussion on the Squid-dev list from around the time
of the actual event a few weeks ago, between me and the primary Squid
developers about the technical aspects involved--and more about the
system I used. The RAM disk trick is something I had never really
experimented with, but is definitely worth trying now that RAM is so
cheap. Anyway, it might be worth reading if anyone is interested in
more specifics of the system in use. Though it wasn't the fastest cache
at the event, it is certainly the fastest dual IDE Squid box you're
likely to run into and is worth looking to for examples in configuring
your own low cost Squid machine.

-- 
Joe Cooper <joe@swelltech.com>
http://www.swelltech.com
Web Caching Appliances and Support