You could also try HAProxy for the frontend instead of a full apache process that only uses ProxyPass.
ericmoritz
· 1 year ago
Thanks Grant. I'll give it a whirl. I'm currently trying different frontend solutions. I tried lighttpd but it doesn't rewrite the location header correctly. lighttpd 1.5 supports this but I'll have to compile it myself.
I'm also trying nginx as a reverse proxy, which appears to add a couple milliseconds to the request. I don't know why.
nginx with mod_wsgi behind an apache proxy performs maybe 1 or 2 milliseconds faster than apache to apache with mod_wsgi.
I'll have the official numbers tomorrow sometime.
Michael Watkins
· 1 year ago
Perhaps its the implementations of flup and scgi which make the difference?
For some reason I found the reverse in my own comparison SCGI, not proxy, (both lighttpd and Apache 1.3) had the lowest overhead:
As you'd expect a Python SCGI server should deliver slightly better performance than a full stack Python web server. There appears to be little difference between the Apache and lighttpd implementations of SCGI (its a pretty simple protocol) and they perform more or less identically. What surprised me is the overhead of Apache proxy (note I am only comparing Apcahe 1.3 - perhaps that has changed in 2.x).
ericmoritz
· 1 year ago
That's interesting. It may be the fact that flup has to translate the scgi headers to a WSGI dictionary to pass it off to the WSGI application. I couldn't imagine it adding to much overhead but it is still an extra step. HTTP Headers to SGCI to WSGI instead of HTTP Headers -> WSGI that the other solutions provide. I don't know much about QP but it looks like all it's doing is splitting on the SCGI headers and passing them off. It could also be that QP's web server implementation is slower than QP's scgi implementation. QP's web server is definitely doing more work than QP's scgi handler based on a quick glance at hub/web.py
Playing with python's hotshot profiler may lend some light to why flup is slower when QP's implementation is faster than mod_proxy.
I'll set up QP on my machine to get comparable timing numbers to my tests.
Rafał Jońca
· 1 year ago
I've tested nginx FCGI and WSGI in the same environment (Django just after standard install) and from there WSGI on nginx was twice as fast as FCGI with flup. This is somewhat similar to your Apache results.
To have mod_wsgi for nginx compiled, you have to applay manually one patch (it is there but not worked properly). The patch only change one function name.
ericmoritz
· 1 year ago
A buddy of mine had created Ubuntu .deb for nginx with mod_wsgi compiled in that I was able to use.
I'm seeing similar numbers with an apache frontend proxied to nginx with mod_wsgi that I'm seeing with apache proxied to another apache server with mod_wsgi with maybe a 1 or 2 milliseconds less than apache/mod_wsgi.
William
· 1 year ago
For info, I've made the same type of concerns some time ago. Finally, I've decided to develop a small wsgi server called FAPWS based on Libevent. This is not yet a "production" application, but it show clearly that plugin nice library to Python could be a solution to tackle both performance and memory foot print. I know internet websites running Django with FAPWS with an uptime of several months. Interestted people are welcome to help in this project. Because FAPWS is very light, I'm running several instances of it (for example 1 for static files and 2 instances for django) and using lighttp or Pound to be the front end and the load balancer.
Michael Watkins
· 1 year ago
I tried fapws2 but ran into compilation issues. Even still it would have been academic for me as WSGI has issues on Python 3.0 (at the very least needs some rework to deal with the new notion of strings and byte strings) and apparently there is no move in that community to fix them at present (according to some notes in bug tracker). I'm aiming to have all parts of my basic application building stack available for both Python 2.x and 3.x and WSGI currently fails hard on 3.0.
Then again a lot of common Python tools seem to be some distance away from supporting Python 3. The one I miss the most is docutils.
Nick
· 1 year ago
William, I am using fapws for a few month. It works quite well, but every django exception kills all instances of fapws. Are there any ideas how to prevent it ? For now, I made a checker script which watchdog fapws and restart it if needed.
All Comments
I'm also trying nginx as a reverse proxy, which appears to add a couple milliseconds to the request. I don't know why.
nginx with mod_wsgi behind an apache proxy performs maybe 1 or 2 milliseconds faster than apache to apache with mod_wsgi.
I'll have the official numbers tomorrow sometime.
For some reason I found the reverse in my own comparison SCGI, not proxy, (both lighttpd and Apache 1.3) had the lowest overhead:
http://mikewatkins.ca/2008/10/22/qp-lighttpd-ss...
As you'd expect a Python SCGI server should deliver slightly better performance than a full stack Python web server. There appears to be little difference between the Apache and lighttpd implementations of SCGI (its a pretty simple protocol) and they perform more or less identically. What surprised me is the overhead of Apache proxy (note I am only comparing Apcahe 1.3 - perhaps that has changed in 2.x).
Playing with python's hotshot profiler may lend some light to why flup is slower when QP's implementation is faster than mod_proxy.
I'll set up QP on my machine to get comparable timing numbers to my tests.
To have mod_wsgi for nginx compiled, you have to applay manually one patch (it is there but not worked properly). The patch only change one function name.
http://media.mnjournal.com/nginx_0.6.32-3ubuntu...
I'm seeing similar numbers with an apache frontend proxied to nginx with mod_wsgi that I'm seeing with apache proxied to another apache server with mod_wsgi with maybe a 1 or 2 milliseconds less than apache/mod_wsgi.
Then again a lot of common Python tools seem to be some distance away from supporting Python 3. The one I miss the most is docutils.
I am using fapws for a few month. It works quite well, but every django exception kills all instances of fapws. Are there any ideas how to prevent it ? For now, I made a checker script which watchdog fapws and restart it if needed.