On Thursday 11 July 2002 01:51 pm, you wrote:
> I have had the experience of dealing with Apple's new XServe on Mac OS X
> Server. Apple includes an HTTP accelerator called webperfcache that
> provides extremely fast performance (over 2000 hits/sec on small-size
> web pages).
I question the relevance of that. That hit rate would put you around 20
million pageviews per day -- enough traffic to put you in the top 100 web
properties. Even if you could put all of that on a box, I don't think you
would want that single point of failure.
> I'm assuming that this performance is due to either the multithreaded
> nature of Apple's webperfcache application and/or some kernel hooks.
The multithreading may help (assuming this is a multi-proc), but your
second guess is probably closer. When you develop for one task on one
platform, you can really tune the crap out of it.
> Squid's performance is about half what webperfcache is on Mac OS X and
> only slightly better than Apache (Squid is in http accelerator mode of
> course). Your previous discussion on this thread has revealed that even
> in async-io mode, Squid will not significantly benefit from multiple
> processors.
Run two squid and load balance them. As noted above, once you pass 400
req/sec or so, load balancing/failover is a Good Thing, anyway.
If webperfcache and apache are both using multiple processors (and squid
isn't), I'd say squid is holding its own just fine.
> Are there any development plans to make Squid more multi-processor
> friendly? With Apache 2.0 coming into widespread usage with its own
> accelerator and proxy cache features, is Squid still a viable option?
I have not messed with Apache 2 (it still lacks 3rd party modules). It
should suffice for simple proxy duties, but it still lacks the hierarchy
and failover abilities of squid. In a cluster design, a rev. proxy like
squid is still the better option.
-- Brian
Received on Thu Jul 11 2002 - 13:01:29 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:09:13 MST