Question about long-running web scripts

David Hutto dwightdhutto at gmail.com
Thu Oct 25 08:53:11 EDT 2012


On Thu, Oct 25, 2012 at 8:03 AM, Tim Golden <mail at timgolden.me.uk> wrote:
> 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.
>>

I'd say that is the same as py, unless it's a cron job to limit script
iterations

>> 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?

The server should call a the script, or script.sleep()

There are also server options to setup when a script is run, other
than a cron jo for php.

>
> (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
> --
> http://mail.python.org/mailman/listinfo/python-list



-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com



More information about the Python-list mailing list