If you are managing a medium/high traffic Drupal server, then you must already be familiar with terms such as caching, Varnish, Nginx and php-fpm.
When you ask in Drupal forums and discussions for HTTP Caching/Accelerators the first answer you will get is Varnish.
While Varnish is excellent and probably the most feature-rich reverse proxy around, it would not integrate well with our existing server setup.
One of the requirements is SSL. Varnish does not support SSL and it is not even in their long term plans (reason here https://www.varnish-cache.org/docs/trunk/phk/ssl.html), so we would need another SSL terminator to handle SSL.
That would amount to a total of two additional servers for caching and the chain would look, from something like this
visitor —-> Web Server —-> PHP CGI
visitor —-> SSL Terminator —-> Varnish —-> Web Server —-> PHP CGI
Νginx gives us the possibility to “merge” three of those steps in to one, simplifying the maintenance of the whole server without sacrificing flexibility and features.
Another requirement was that HTTP caching would be used only on some websites while others would not make use of the additional caching mechanism. It just made no sense in further complicating their setup if they would get none of the benefits.
Nginx can enable/disable the cache on each “server” directive without affecting the existing sites on the server.
Another great module that nginx supports is nginx_cache_purge. What this module does is to add support for PURGE requests and they are used to expire a specific page cache. This makes possible to expire the cache existing pages from within Drupal when they are updated instead of waiting for the cache lifetime to end. This is the best of both worlds since the site will keep the performance of a high TTL cached/static page but can be updated in realtime without waiting for a timer to end.
The only thing needed from a drupal site is the drupal Purge https://drupal.org/project/purge module which fully supports Nginx purge.