varnish+nginx slower than just nginx??

Looks like you're already using pressflow, but you could take a look at:

https://www.varnish-cache.org/trac/wiki … hAndDrupal">https://www.varnish-cache.org/trac/wiki/VarnishAndDrupal

There are also some articles on best practices:

http://kristianlyng.wordpress.com/2010/ … practices/">http://kristianlyng.wordpress.com/2010/01/26/varnish-best-practices/

Varnish can provide benefits when running on the same machine as the other software, but it's really meant to have a dedicated box.

Thanks Guspaz, indeed I'm already using it and I'm sure I have work to do on settings and configuration.

But at the moment I've just installed pressflow (and the needed modules for Drupal) and haven't created any content therefore I don't think that should have much of an impact: the few existing pages (the front created by pressflow) has been the same all day and should be in cache.

Thanks again

but I am using 32-bit and I see from you second linke that that's not ideal.

Thanks again

100k pageviews/month = 3k pageviews/day = one pageview per 30 seconds on average.

Even at 100 times that figure, putting anything in front of nginx is unlikely to perform better than nginx on its own, especially if everything is running on the same box.

Switching to 64-bit just for the sake of Varnish is likely to incur penalties in other areas of your software stack. For example, Drupal will probably consume a lot more RAM on 64-bit, leaving less RAM for Varnish to juggle with.

Also try varying the concurrency (-c) of your benchmark. Your software stack and configuration may not be optimized for that particular concurrency level.

@hybinet:

100k pageviews/month = 3k pageviews/day = one pageview per 30 seconds on average.

Even at 100 times that figure, putting anything in front of nginx is unlikely to perform better than nginx on its own, especially if everything is running on the same box.

agreed, wanted to experiment while the box is still private but will definitely not put varnish when it goes live

@hybinet:

Switching to 64-bit just for the sake of Varnish is likely to incur penalties in other areas of your software stack. For example, Drupal will probably consume a lot more RAM on 64-bit, leaving less RAM for Varnish to juggle with.

will never go to 64-but unless it's needed and it's not here

@hybinet:

Also try varying the concurrency (-c) of your benchmark. Your software stack and configuration may not be optimized for that particular concurrency level.

thanks!

Varnish recommends 64-bit because it relies on virtual memory to perform disk caching; it does no cache management itself (not between different cache levels, anyhow), it simply shoves everything in RAM and lets the OS decide what should be in RAM or on disc. If you're running a 32-bit OS, you're not going to be able to cache more than 3GB of data with Varnish, in RAM or on disk.

Normally, on a linode, we recommend little or no swap space, because it almost never makes sense to dig into swap. Caker says you should have none, I say you should have a bit just to get the never-used stuff out of RAM.

Varnish, on the other hand, isn't like that at all. For a dedicated Varnish machine, it might make sense to have a 1024MB linode with a 20GB swap partition, depending on the workload. But with a 32-bit OS, you'd basically be limited to a 2GB disk cache.

Are you sure your ab results are accurate? 7000 requests per second seems really really fast, I would expect varnish could respond like that, but not the rest of the stack.

If nginx or php-fpm crap out then you're just receiving error responses at a really high rate (ab reports these as non-2xx responses or something like that). Check also the size on the response is right, what ab reports compared to what you see on your browser.

Also varnish has a utility like top that reports cache hits in real time so you can monitor and see if it's hitting at all. I've had trouble ab, drupal, and varnish, where the ab requests just pass through varnish without hitting the cache - then varnish just could add a little overhead to the responses and slow things down a bit…

@hybinet:

Even at 100 times that figure, putting anything in front of nginx is unlikely to perform better than nginx on its own, especially if everything is running on the same box.

Yep.

I've got a 1GB node running Apache behind nginx. 10M hits per month, out of which some 2M hit Apache. nginx doesn't even break a sweat. CPU use in average 80% (out of 400%) mostly because of very poor SQL and each hit has to scan and sort through tens of thousands of unindexed joins (MySQL localhost). Unfortunately I can't change that, I just run the show for a client.

You might also want to try using -k as a lot of the requests you get will be on an already active connection (assuming images, css, js on the page). Your main focus should still be on PHP/MySQL as nginx/varnish are definitely not the limiting factor (unless you are caching every page with nginx/varnish).

@diolemo:

You might also want to try using -k as a lot of the requests you get will be on an already active connection (assuming images, css, js on the page). Your main focus should still be on PHP/MySQL as nginx/varnish are definitely not the limiting factor (unless you are caching every page with nginx/varnish).

Thanks, diolemo. Adding -k to the ab run made a huge difference in the results. Seems that the SSL connection time outweighs all other factors in my case.