Understanding Python from a PHP coder's perspective

[Chris Angelico]

On Tue, Dec 8, 2015 at 8:21 AM,  <villascape at gmail.com> wrote:
> Per https://wiki.python.org/moin/PythonVsPhp, "The vast majority of Python Web applications are run in a separate process. This has some important implications."
>
> From a PHP background, guess I just don't understand the concept of "separate processes".  What does this mean, how is it implemented, and what are the "important implications"?

This is talking about how PHP code is generally run inside the
server's process. I'll use Apache as my example, as that's what I have
handy.

There are a couple of ways that Apache can run PHP code. One is
spawning a new process for every page request, and using CGI mode; and
the other is a thing called mod_php, which runs PHP as a module inside
the Apache process. The first one gives great isolation between pages,
but it's horribly slow (every page request has to start a process -
cheap on Unix, expensive on Windows - and fully initialize PHP, which
is expensive everywhere); the second fixes the performance problem, at
the cost of maintaining hidden state in the Apache process. Most PHP
web sites out there are using (the equivalent of) mod_php. Coupled
with features like persistent database connections (another way of
improving performance at the cost of isolation), or changes to PHP
error handling configs, this can create *very* debug-hard problems
that depend on the exact distribution of work among Apache processes.
This becomes even worse if you have multiple PHP web sites running in
the same Apache instance; any one of them could interfere with any
other.

In contrast, Python code is run in a separate process from Apache. It
openly and honestly does NOT reset its state between page requests
(which you do need to be aware of; for instance, always commit/roll
back your database transactions before returning), but there's no way
for Python to affect Apache or vice versa. If you have two Python web
sites on the same server, they are completely isolated from each
other.

As well as the massively-beneficial implications of this isolation,
there are some less positive effects. One is that you need to have a
complete Python process for each site you have active - or else pay a
hefty startup penalty on first page load. This can cost a lot of
memory, especially if you have a lot of isolated little web sites
running. But the benefits of isolation are usually worth that cost;
it's possible to run the web server as one user (say, www-data) and
the application server as a different user (say, python-app), and then
grant file system permissions differently to the different users. You
could have two apps running in different versions of Python, or with
different versions of third-party packages. You can put memory or CPU
usage limits on the Python process, without worrying about the web
server itself going down.

It's a very different structure from the mod_php model, and worth
understanding. Personally, I think the costs are worth it; but if you
have a mostly-static web site with just a tiny amount of scripting in
it, it might be better to follow a PHP model.

ChrisA