Re: [squid-users] Moving to squid from inktomi

Marshall wrote:

>>If disk becomes your bottleneck, you're toast. Disk cache is king at
>>these speeds. Consider going with 1 or 2 IDE disks and sink the
>>savings into more RAM.
>
>
> I guess you are saying go heavy on RAM no matter what, and buy more disks
> if possible? Is there any perf hit to having a cache partition on the
> same disk as OS and swap?

Brian is right. RAM is the most important thing if you want peak
performance from an accelerator--if your entire popular working set will
fit in RAM, then your bottleneck becomes CPU. With processors going up
to 2.53GHz, you can reasonably expect to get 400-600 reqs/sec from a
single machine (I haven't benchmarked machines at this speed--I've only
gone as high as 1.26, so I can't make that assertion very strongly,
since other issues may arise). A 1.26Ghz machine can push 300+ reqs/sec
from a predominately RAM workload.

>>>can get 2 1650s with this config from Dell for ~$4,300 which is well
>>>under budget which is good. I am leaning towards FreeBSD. Based on
>>>old
>>
>>Between Linux and FreeBSD, go with the one you know. The vfs and NIC
>>performance should be fine on either one. Many around here like
>>ReiserFS (meaning Linux), but I found it more practical to just wipe
>>the cache partition on reboot.
>
>
> I actually prefer Solaris, but it seems like most people are running
> FreeBSD or Linux, and of those 2 I prefer FreeBSD. I like Solaris for
> multi-tasking and NFS (and multi-cpu), but FreeBSD will probably kick its
> butt at single-tasking with a single cpu. Any arguments for Squid/Solaris
> out there?

Doesn't matter in the case of an accelerator. If disk I/O were playing
a major role Linux+ReiserFS is about 20%-30% faster than
FreeBSD+SoftUpdates all other things being equal. But it isn't, so
don't worry about it. FreeBSD probably is faster than Solaris on an
Intel platform. Multi-CPU doesn't buy you anything except more
complexity in your deployment (you can run two Squid processes to take
advantage of the second processor, but it probably isn't worth it--get
the fastest P4 your budget allows, and it will run pretty close to a
Dual Xeon at 1.5GHz).

>>Faster drives and multiple procs will not help you here. More RAM and
>>faster procs will help, but you can probably hit 300 req/sec each
>>as-is. It depends on the size of the request of course -- I deal with
>>a lot of zips and mp3s, so my req rate is probably lower than your's
>>will be.
>
>
> Even allowing for growth I can't see ever having more than 50,000 objects
> (average 40KB, ~2GB total) in the cache. Does this make any difference?
> Based on what I read into this so far, I would probably stick with the
> 2x18GB 10K with 5.2 seek time, but go woth 2GB RAM, instead of going to
> 15K 3.9 seek time disks and leaving the RAM at 1GB. I guess I could
> always add RAM later, but it is damn cheap right now. It sounds like
> processor is not really an issue.
> Another scenario might be to add a third disk and keep the RAM at 1GB. But
> I guess it seems ridiculous to have 54GB of storage for 2 to 3 GB of
> cacheable objects. Unless seek time is really the end of the road. What
> do you think?

Yes. RAM. Forget faster disks, they shouldn't come into play if you
can fit your workload into RAM. I would say you could get by with IDE
(and you probably could with Brian's picky writes patch to keep disk
write contention lower), but Squid does insist on writing out all new
objects.

However, CPU /does/ matter. You will hit it as a bottleneck once you've
moved the entire working set into RAM. A 1.26GHz machine can push 300
reqs/sec from RAM under just about any circumstances (and more on easier
workloads--I've run 400 on a 1GHz CPU, but only for a couple of hours).
  So to go to 600, you'll need twice that speed, enough RAM, and some
good luck.

-- 
Joe Cooper <joe@swelltech.com>
Web caching appliances and support.
http://www.swelltech.com