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

joe wrote:
>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.

This is precisely the reason why me and many other folks out here are so very
interested in your entry joe .. and i bet all of us at somepoint of time have
referenced http://www.swelltech.com/pengies/joe/squidtuneup/t1.html
:-)
i hope that all the squid developers are trying their best to push squid in
terms of sheer performance
TIA
khiz

--- Joe Cooper <joe@swelltech.com> wrote:
> 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
>

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com
Received on Wed Dec 19 2001 - 00:17:37 MST