On May 5, 3:32 pm, cd34 <[email protected]> wrote: > If you're going to use nginx, there's no reason to involve apache. > nginx has a 3rd party wsgi module that works quite well. You'll need > to make a minor change to your middleware.py to remove the 3 lines > that allow turbogears to serve the static files. With those lines > removed, only the dynamic pages would be served through wsgi and the > rest is handled through nginx.
Except that static files would need to be served by a separate nginx instance in front of the nginx instance running nginx/mod_wsgi. This is because WSGI is blocking for individual requests and so any concurrent static file requests handled by same nginx worker process will block if handled by same process as WSGI application. > nginx will outserve apache on static > files 5:1. It's mod_wsgi performance is about 15% faster. If there is a performance difference for dynamic Python web application, it is only going to be for a simple hello world type program. When you load up a large Python web framework such as TurboGears the bottlenecks are not going to be in the web hosting mechanism but the application and database. When looking at what the resultant overall request time is, that part which relates to the underlying web hosting mechanism is going to be a very small percentage, much less than 15%. If you are seeing as much as a 15% difference for a realistic application test, then you aren't comparing comparable configurations and so could be configuring one or the other in a sub optimal fashion. > http://turbogears.org/2.0/docs/main/StaticFile.html > > Apache does have threaded models - mpm-worker for one, which does > support mod_wsgi. It is incompatible with mod_php which requires mpm- > prefork. If you need php and wsgi and want to use mpm-worker, you can > run php with fastcgi. If you need Apache prefork MPM because of PHP running inside of Apache, then run your Python web application under mod_wsgi daemon mode. This is the fastcgi equivalent in mod_wsgi which separates Python application into its own process, with number of processes and threads being able to be configured separately to the main Apache server child processes. > nginx also has ncache.org which does caching. If you were going to > use apache, I'd suggest varnish in front of apache with mod_wsgi. > There are unique issues with varnish dealing with IP addresses handed > to apache, so, if you are doing anything with IP addresses, you'll > need to use X-Forwarded-For. Given that for nginx/mod_wsgi you still have to use a separate nginx instance for static files, and that for large applications there is no appreciable difference in performance between nginx/mod_wsgi and Apache/mod_wsgi, you may as well just use nginx in front of Apache/ mod_wsgi. If you look around you will find this configuration is quite popular, as you get fast static file serving with nginx, but stability of Apache/mod_wsgi for dynamic web application. Use of nginx front also helps to buffer Apache/mod_wsgi from slow clients as request will not be sent to Apache/mod_wsgi until completely received. The nginx also acts as a buffer of sorts for the response when dealing with slow clients as well. This means that Apache/mod_wsgi is only tied up with request for minimum time possible and with keep alive off in Apache, you don't tie up processes/threads with keep alive connections and thus get better utilisation and reduced memory usage. With nginx as front end, you can also for static files that need to be password protected by the web application, use X-Accel-Redirect response header back to nginx front end to have nginx serve static file from a private area of URL namespace. This yields much better performance over the WSGI application returning its own iterable wrapper for files or even than wsgi.file_wrapper extension. Overall, for real world dynamic Python applications the performance differences between different web hosting mechanisms are going to be very little. So, since all can be made to work, you are generally better off just choosing that solution which fits your mind set and which you find to be easy to install, configure and maintain. Issues such as stability and quality of documentation and ongoing support should also be considered for critical production systems. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
