Hey Peter - long shot, because I don't know your setup or exactly what you're trying to do, but for static content, have you thought of trying it without squid?
We've been using nginx a lot and get pretty stellar results in comparison to Apache when it comes to straight html, particularly when the concurrency goes up. We served 440K ~1MB (!) PIs in about 5 hours with nginx on a dual-core Xeon with CentOS 5 with 2GB RAM and the thing didn't break into a sweat; use system sendfile, keep everything in kernel cache RAM and you're laughing. In another project, using a mix of static content and dynamic upstream (FastCGI), nginx served up 38.3 million static files and over 27 million upstream requests in 7 days, and I never once saw the load on the nginx box go above 0.5 - I've seen Apache boxes crying under much, much lighter load than that.
If you're testing both Apache and nginx against Squid, at worst squid might be the bottleneck, and also it seems maybe you're really testing the respective upstream modules, rather than the serving capacity. If you just want to chuck out flat HTML, do try nginx on its own if you haven't already. I'm just guessing, but intuitively I reckon introducing Squid into the equation might slow nginx down, particularly if it's all on the same box, because of squid's memory usage, and the extra pile of context switches.
Like I say, I don't know anything about your setup so I know I'm just guessing wildly about this, but my experience of nginx has been so overwhelmingly impressive that I'm loath to use Apache at all these days.
Comment
Hey Peter - long shot, because I don't know your setup or exactly what you're trying to do, but for static content, have you thought of trying it without squid?
We've been using nginx a lot and get pretty stellar results in comparison to Apache when it comes to straight html, particularly when the concurrency goes up. We served 440K ~1MB (!) PIs in about 5 hours with nginx on a dual-core Xeon with CentOS 5 with 2GB RAM and the thing didn't break into a sweat; use system sendfile, keep everything in kernel cache RAM and you're laughing. In another project, using a mix of static content and dynamic upstream (FastCGI), nginx served up 38.3 million static files and over 27 million upstream requests in 7 days, and I never once saw the load on the nginx box go above 0.5 - I've seen Apache boxes crying under much, much lighter load than that.
If you're testing both Apache and nginx against Squid, at worst squid might be the bottleneck, and also it seems maybe you're really testing the respective upstream modules, rather than the serving capacity. If you just want to chuck out flat HTML, do try nginx on its own if you haven't already. I'm just guessing, but intuitively I reckon introducing Squid into the equation might slow nginx down, particularly if it's all on the same box, because of squid's memory usage, and the extra pile of context switches.
Like I say, I don't know anything about your setup so I know I'm just guessing wildly about this, but my experience of nginx has been so overwhelmingly impressive that I'm loath to use Apache at all these days.
Anyway, hope all's well!