Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have been running nginx -> uWSGI, and now we are evaluating putting Varnish as a caching layer between nginx and uWSGI (similar to

But, nginx only supports HTTP 1.0 on the back so it will have to create new connections with Varnish for each request.

Many recommend running nginx in front of Varnish, but wouldn't it make much more sense to use something like Cherokee so that you eliminate the HTTP connection overhead since it supports HTTP 1.1 on the back?

share|improve this question
Why don't use nginx caching? – rvs Apr 18 '11 at 8:44
Persistent connections would allow for more data throughput. My tests with Nginx and memcached showed that without keep alive Nginx could fetch from memcached at a rate of 10k/sec while with keep alive it would do 12k/sec. Question is, do you really need this difference? Is this worth spending precious developer time on? – Martin Fjordvald Apr 18 '11 at 13:04
Probably not -- Roberto De Ioris, the creator of uwsgi, just posted on the mailing list that he is working on adding uwsgi protocol support to both varnishd and haproxy so nginx may soon be able to speak to Varnish in uwsgi. As he says, "http parsing is 300% slower than uwsgi parsing." – espeed Apr 18 '11 at 14:12
nginx caching doesn't support stuff like ESI for dynamic pages. Also see – espeed Apr 18 '11 at 15:02

We debated this as well when putting in our backend cache layer, we are also using nginx but with squid and a JVM that serves content.

If you aren't using any functionality that is unique to nginx you could switch, we had already built a couple nginx modules.

You should consider what the actual overhead of that connection setup is vs the end-to-end request. For us when testing it was always <2ms even reading an asset from memory cache took more than that to respond (>5ms).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.