Python as a Server vs Running Under Apache

grahamd at dscpl.com.au grahamd at dscpl.com.au
Wed Jan 4 20:55:07 EST 2006


fuzzylollipop wrote:
> there are lots of things you can't do or can't do easily or can't do at
> efficiently in Apache using python as cgi or as anyone would more
> likely assume mod_python. anything that requires any shared state or
> shared resources in Apache is next to impossible. Doing similar things
> in an app server or network application framework like twisted is
> trivial.

What one really should be identifying here is that different tools are
better for different jobs.

Apache is a web server, and it isn't necessarily practical or sensible
to try and shoe horn it into service as a full blown application server
by and in itself. At the same time though, I would suggest that
something like Twisted is in itself not always the best solution
either, ie., to take an application server, and try and bolt on to it a
web server. Yes Twisted can perform as a web server, but when compared
to the functionality and configurability that Apache provides as a web
server, it is always going to be a lessor cousin in that role. If you
do not need the full power that Apache can provide and can live with
the lessor abilities inherent from running the web server as a
component within the application server, then great, but this isn't
necessarily going to suit everyone either.

Thus one is still faced with the question of whether you should embed
the application in the web server, or wrap a web server around the
application. Unfortunately from what I have seen, often the decision is
made based on the narrow focus of expertise of the developers involved.
A web developer will be dismissive of the application developer and
vice versus. Each will say that it is trivial if done in the system
which embodies their area of expertise, although usually that is said
without them really knowing how they will achieve the part they don't
know too much about. The strongest personalities thus will win as to
how the system is built.

The alternative is to accept that both Apache and application
frameworks such as Twisted are each good in their own space and use
both, bridging between the two as necessary. This could be done using
simple protocols like XML-RPC or more sophisticated messaging system
protocols where persistent connections can exist between the Apache
child processes and the backend application server thus avoiding the
creation of socket connections on every request. The use of messaging
systems also means that presence information can extend into the realm
of the web server and it can be easier to deal with failure or
unavailability of components of the backed system.

Keeping a split like this means you also have the added benefit that
you don't end up with application server code which is somehow
inherently dependent on or knowing that it is being used purely within
the context of a particular web server. You don't end up with
application server code being tied to the use of a specific means of
rendering web pages. With this sort of split it doesn't matter whether
you use CGI, mod_python, mod_perl or PHP for web page generation.
Provided that the interfaces between the two are well defined, you can
change the application server code structure as much as you like and
the web page generation code doesn't need to change. The opposite also
applies in as much as changes to the web page generation code shouldn't
affect the application server code.

Overall I would have to say that you are both right and wrong. Where
the state is served purely by the use of the database, there is nothing
wrong with Apache/mod_python in itself being used. Where the state also
embodies the need to have active agents which operate on that data,
possibly independent of web requests, then a back end application
server which embeds the core functionality of the application would be
better. In doing that though, it doesn't mean that Apache has to be
discarded as the web server, and a web server embeded in the
application server be adopted. Depending on the requirements, you will
get a more flexible, more easily maintained system if a combination of
the two technologies is used.

Anyway, that statisifies my daily need for a good rant. ;-)

Graham




More information about the Python-list mailing list