"A buddy of mine had created Ubuntu .deb for nginx with mod_wsgi compiled in that I was able to use.
http://media.mnjournal.com/ngi......
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." - Eric Moritz
"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 definately doing more than QP's scgi handler.
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." - Eric Moritz
"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 to milliseconds faster than apache to apache with mod_wsgi.
I'll have the official numbers tomorrow sometime." - Eric Moritz
