Question about long-running web scripts

[Tim Golden]

On 25/10/2012 12:45, Gilles wrote:
> I'd like to check something about running Python web applications.
> 
> Generally speaking, the reason scripts run faster when called
> through FastCGI or the mod_* modules, is because the interpreter is
> already up and running. But when running PHP scripts, this does
> nothing about fetching the file from disk, recompiling, rerunning it,
> and usually reconnecting to the database.
> 
> OTOH, Python web scripts can be written as long-running scripts: In 
> this case, what is the added-value of using FastCGI? Why can't the
> web server simply call the Python script directly, just like CGI?

(Your question is a little confused at the end. I'm choosing to
understand: why can't we just run Python one-shot, like CGI? The likely
alternative meaning is: why can't the incoming request be routed to an
already-running Python program -- which is not, of course, what CGI
generally does. Hence my confusion).

The answer is: it can. CGI is a protocol rather than anything else. In
front of a CGI exchange is the browser (or some other web client).
Behind it is some program which is capable of producing a valid HTTP
response, including a Python program.

It's perfectly possible to run a usable website against Python running
one-shot. You won't get terrific performance out of it, but for a
website which doesn't expect humungous amounts of traffic, it'll work fine.

The amount of time it takes a half-decent, even shared, server to start
up a Python process, connect to a database, pull stuff together, and
send a response will likely not impact on an average user's experience.
As long as too many of them don't try to do that at the same time.
Exactly where the line is drawn will depend on your particular hosting
solution, your assumed traffic, and your users' expectations as to
responsiveness.

TJG