All, I have been looking into methods for interfacing CherryPy Python code with an Apache web server, in order to compare the capabilities and limitations of each. My notes on this subject follow.
The discussion is about the "glue" between CherryPy and Apache. Essentially, Apache Web Server == <some glue layer> == CherryPy code Apache receives a request for dynamic content. Apache would then utilize the glue layer, and the glue layer would invoke CherryPy code to generate dynamic content. At this point, the glue layer would pass the resultant data back to Apache, for delivery to the client. The glue acts as an interface into The glue layers fall into two main categories: 1) Redirecting HTTP requests from Apache web server to CherryPy web server. CherryPy web server is the "glue layer" - the difference in these methods is in how Apache directs the request. 2) Direct invocation of Python via an Apache mod and a documented Python interface. The "glue layers" here involve configuring Apache to be able to execute the CherryPy code via some Python interface. Note: With all methods in both categories, it is possible to set-up Apache to deliver static content, and have CherryPy handle dynamic content - which is the primary benefit for running CherryPy behind Apache. There are 5 "documented" methods for interfacing CherryPy with Apache, according to the CherryPy wiki. That wiki describes the steps to complete such a hook-up. However, it is out of date in many places and so many of the steps have changed for more recent versions of CherryPy - but it is a reasonable starting point, when/if the time comes. Other website links with pertinent information are also included. http://tools.cherrypy.org/wiki/BehindApache The 5 methods are: modRewrite modProxy FastCGIWSGI ScgiWsgi modPython Category 1 methods: * modRewrite * modProxy - Of these 2, modRewrite appears to be more popular, and better documented. Advantages of category 1: > Easier set-up: Since the 2 web servers essentially run separately, they can be set-up independently > More frequent, recent and useful documentation (incl. wiki/blog posts) on how-to set these up Disadvantages: > Still running 2 separate web servers - which means a slight additional overhead for serving requests from the AI server to the AI client. However, this additional overhead is small in comparison to the time taken to *generate* the dynamic content. Category 2 methods: * FastCGIWSGI * ScgiWsgi * modPython - Of these, modPython appears to be the most popular with highest support. WSGI seems to have a higher set-up cost, but the WSGI interface is more standardized (so a set-up using WSGI may be more portable to other web servers). Advantages of category 2: > Apache directly calls code to generate dynamic content, instead of passing a HTTP request off to another server. > This results in theoretically faster content delivery (how much faster depends on a number of factors and may be insignificant). > This is a more integrated approach Disadvantages: > More difficult set-up time, more potential configuration issues > Potentially less portable than other solutions. Note: when I say portable here, I am referring to the ability to swap out the method for delivering the dynamic content. For example, with modProxy, at some point in the future, it would be theoretically possible to swap out Apache for another web server, and configure that web server to forward requests to the CherryPy server. With category 2 methods, the "glue" piece is more strictly tied to both Apache and CherryPy. Additional Links of interest: CherryPy on Apache 2 with ModPython: http://www.electricmonk.nl/log/2007/10/13/cherrypy-on-apache2-with-mod_python/ "Running CherryPy behind Apache" http://andrewcoxtech.blogspot.com/2009/01/running-cherrypy-behind-apache.html Configuring CherryPy or Apache to survive sudden bursts in requests (e.g. a link on slashdot.org points to a low bandwidth site): http://amix.dk/blog/viewEntry/119 -Keith
