Re: [squid-users] benchmark test

Bgs himself wrote:

> On Tue, 19 Feb 2002, Joe Cooper wrote:

>>Of course...maybe you're talking about website accelerator performance,
>>in which case all these numbers go out the window. Squid is much faster
>>from a RAM only workload, so your high numbers for those last two boxes
>>get to be more realistic.
>>
>
> In the first step I'll need an accelerator and I'm putting more energy in
> estimating accelerator performances.

So forget SCSI. Use a couple of cheap, small, IDE 7200 RPM disks, and a
/ton/ of RAM (enough to fit the whole working set).

A 1GHz machine will push 250reqs/sec easy. 300+ is not an unreasonable
hope with proper tuning. A 1.5GHz Athlon might top 400.

> Reading your mail a couple of questions came to my mind:
>
> - I saw tests about squid/disk numbers. Increase from 1d->2d was a real
> improvement. 2d->3d gave also noticable performance increase. From the on
> I saw very little difference. Isn't it better to have two servers with 2
> disk than having one with 8 disks (about the same price or even
> cheaper) ?

Yep. Very much so. You can draw 120 reqs/sec or more from two IDE
disks plus a bunch of RAM for about half the price of a SCSI based
system that can do 180. So its 240 reqs/sec from two boxes vs. 180 from
one. But, again, for accelerators the choice is obvious: use cheap
disks, a fast CPU and enough RAM to store your whole site. For web
caching, the choice isn't as obvious--because you don't control the
sites or the clients, you have to balance those multiple boxes somehow,
and many prefer to use a single big box to maintaining several smaller
ones plus a balancing machine (either a WCCP router, and L4 switch, or
some clever usage of Linux Virtual Server on one of the proxies or an
extra box).

> - When running multiple squids on one box, which gives better
> performance:
> - 3 squids in: "frontend" -> 2 local parents setup

Goodness no! That's crazy talk.

> - 2 squids and software tcp round-robin traffic distribution ?

Nope. Not that either. Split traffic on the last octet of the
destination IP. If in an accelerator situation, you can probably drop
the second processor as you can go plenty fast without it. But if you
/do/ need it, then you'll be able to split based on actual
IPs--hopefully you'll know roughly the load each IP will see, since you
control them.

This layout avoids redundant data entirely, so kills the need to have
the Squids know each other.

So for example, if you have a backend website hosted on three servers
called "images" on IP 192.168.1.1, "main" on IP 192.168.1.2, and "media"
on IP 192.168.1.3, and you know that the images server gets hit
significantly harder than the other two servers combined you would have
redirects that look like this (assuming ipchains, since it is simpler to
explain than iptables rules):

ipchains -I input 1 -d 192.168.1.1 80 -p tcp -j REDIRECT 3128
ipchains -I input 1 -d 192.168.1.2 80 -p tcp -j REDIRECT 8080
ipchains -I input 1 -d 192.168.1.3 80 -p tcp -j REDIRECT 8080

Here we have Squid1 on port 3128 and Squid2 on 8080. Squid1 is
completely ignorant of the existence or the data of Squid2, and vice
versa...and we like it this way.

> The first seems more failproof, the second a bit faster. Or is it only a
> wild guess?

Wild guess, I reckon. As both suggestions are quite problematic and
less than ideal (though they would work, and I've seen it done that way
a few times on this list).

> I'm encountering more and more questions and I'm still far from making
> estimates :/

Relax. Buy yourself a 1.2GHz box with 2GB of RAM (or 4GB if you've got
a big site to accelerate) and dual IDE disks. Are you really pushing
22464000 requests in a day (260/sec)? If not, that box will probably do
the job just fine.

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