Recently I'm setting up some Python website and it seems the architecture nginx -> uwsgi -> wsgi application is an obvious choice in Python world these days. (Actually I'm migrating a MoinMoin site backed by Apache + mod_wsgi to a newer VM running nginx so I took time to look at nginx-backed deployment possibilities.)

I've read a lot about why there needs to be such indirection layers, and I'm fully aware that the individual techniques involved - nginx, uwsgi and wsgi - are all modern, featureful of very high performance, and all mature as of today. But since in such an architecture there are 2 layers of IPC involved (nginx -> uwsgi and uwsgi -> wsgi application) I've been always wondering about

  • how does the IPCs impact the overall performance?
  • is the impact big enough to have practical implications?

I googled and found no direct answer. So is the IPC overhead small enough or just I didn't find the right keywords?

(BTW I read that Erlang community has produced several HTTP servers that take the user's HTTP request directly to the application code and also have very high performance. I googled but couldn't find a benchmark comparing these 2 approaches)


There is no ipc in the uwsgi->wsgi part. The only connection/ipc is from nginx to uWSGI, and it has practically no-impact (remember, even apache+mod+wsgi in daemon mode uses ipc)

Regarding the Erlang part in your question, there are high-performance http parser for python you can embed in your code too (even uWSGI can be used that whay), but experience showed this is not a good approach for security, versatility and scalability (but obviously you are free to do it). Having a frontend proxy looks like the most reasonable choice (independently by the application server or the language)

  • Thanks for the answer, this clears some of my confusions. As for the nginx -> uWSGI part, is there some detailed analysis on the overhead? If it is so small that virtually everyone ignores it, can you give an estimate to give me some rough idea (like "during a typical HTTP request-response cycle, the IPC only costs...")? Will the IPC be a bottleneck in some extreme circumstances? – xiaq Aug 1 '12 at 9:22
  • The IPC can be of impact when you consume all of the kernel resources (sockets, ports, listen queue). You have to take them into account if you plan to host a highly slashdotted app. Regarding connection times, we are in the order of microseconds, while webapps works in the order of milliseconds/seconds. – roberto Aug 1 '12 at 17:45
  • There can also be a performance difference between INET and UNIX sockets used for the IPC connection on some platforms. Always use local UNIX socket if the option exists. Do be aware that some platforms such as MacOS X have very small send/recv buffer sizes for UNIX socket, so may be necessary to tune that. – Graham Dumpleton Aug 2 '12 at 0:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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