varnish+nginx slower than just nginx??
I'm preparing a server to host a relatively busy website (100k pageviews/month and 25k unique/month on average but expect more the week we relaunch).
Got a Linode 1024, spent a few hours setting up everything:
nginx
php-fpm
mysql
APC
memcache
pressflow (drupal)
all good and a simple ab -n 40000 -c 1000
then I thought "let's prepare varnish as well", did that and run the same ab test and only got 2000 reqs/sec…
everything else is the same and in fact if I now run ab -n 40000 -c 1000
All the settings are default ones, no cutting edge stuff.
Any idea? Cheers
10 Replies
There are also some articles on 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.
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
Thanks again
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!
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.
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.
@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.