Absolutely, Aaron. Load balancing Squid boxes is a great solution
(provides high availability too). But for 10Mbits it's probably
overkill. You can certainly push that much from a single Squid box
without too much hard work.
Our largest boxes are actually pushing over 20 Mbits, but I don't
consider that an 'easy' thing for most folks to do. I had to jump
through a few hoops to make it happen (which was discussed here a couple
months back).
I suspect that we'll be able to push beyond 24 Mbits from our latest
hardware platform (which supports dual Tualatin CPUs, 4GB of RAM, and up
to six Ultra 160 SCSI disks) but I haven't tested it yet. We've also
deployed a dual Athlon 1.4GHz system recently, which might push those
limits a little higher as well--but the client isn't pushing it very
hard yet (probably 5-6Mbits right now, with planned loads up to about
10Mbits by mid-2002).
So, in summary, Squid is an easy and cheap solution for small to
mid-sized networks. It gets a little more complicated for bigger
networks, and more expensive as well (and beyond the $6k price range, if
price/performance is the primary concern, it may be worth looking to
proprietary systems). But I still consider Squid the best option in
almost every case, even large networks (if I didn't, I wouldn't be
selling it--we could be shipping any caching software we want and would
probably make higher margins on proprietary systems due to 'artificial
scarcity' of the software, but Squid allows us the flexibility to do
things that no other platform would).
Aaron Seelye wrote:
> So it would be correct to say that this limitation could be overcome by
> multiple squid boxes and a load balancer? I understand that that's a
> workaround, but if an organization can afford to have 10Mbit or greater
> bandwidth, they can afford an extra $2-3k box and a layer 3/4 switch/load
> balancer.
>
> -Aaron
>
>
>>-----Original Message-----
>>From: Joe Cooper [mailto:joe@swelltech.com]
>>Sent: Wednesday, December 05, 2001 8:26 AM
>>To: Dennis
>>Cc: squid-users@squid-cache.org
>>Subject: Re: [squid-users] Current Performance?
>>
>>
>>Dennis wrote:
>>
>>
>>>I've read a lot about the cache-off,and Im interested in the base
>>>parameters affecting performance, as there seems to be a
>>>
>>wide disparity
>>
>>>in performance, and a lot of the numbers I've seen are
>>>
>>fairly old. What
>>
>>>is the current performance level..and what is the
>>>
>>bottleneck keeping
>>
>>>squid from reaching the high end?
>>>
>>
>>A perusal of the squid-dev archives linked from the
>>squid-cache homepage
>>will give you some good ideas about the current performance (not much
>>different than at previous cacheoffs, though a little faster in 2.5),
>>and where the bottlenecks are and what folks are doing about it.
>>
>>
>>
>>>Also, Freebsd 4.4 is substantially faster than 4.1 (at least at the
>>>networking level)....are there any numbers on squid with P4
>>>
>>and rambus
>>
>>>memory on FBSD 4.4? What is the impact of faster ram?
>>>
>>Network I/O is not a bottleneck in Squid, and generally neither is
>>memory I/O (though it does have some impact, it is small). The
>>bottlenecks in Squid are well-known and aren't easily erased
>>by hardware
>>changes--pure performance of hardware is certainly reflected
>>in Squid's
>>performance, a faster box runs a faster Squid. But simply shifting
>>performance numbers around (i.e. super fast RAM, but with the
>>same old
>>disk subsystem) is going to have marginal impact.
>>
>>A well-tuned Squid performs pretty darn well on low to mid-range
>>networks (1.5-15Mbits), but begins to require a lot more
>>effort to tweak
>>additional throughput out of it beyond that point.
>>
>>I suggest reading up on this subject on the squid-dev list.
>>All of your
>>questions will be answered in quite good detail, I think.
>>--
>>Joe Cooper <joe@swelltech.com>
>>http://www.swelltech.com
>>Web Caching Appliances and Support
>>
>>
>
>
-- Joe Cooper <joe@swelltech.com> http://www.swelltech.com Web Caching Appliances and SupportReceived on Wed Dec 05 2001 - 09:50:02 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:05:14 MST