In my mind, a web app something that runs continuously; therefore, I'm confused by documentation pages that talk about the "end" of a PHP script (eg this one). Such references seem to refer to the end of each web request, but if the script ends there, doesn't that mean that the OS has to setup a whole new process for each request? That seems unlikely, because spinning up a whole new process is expensive, and be very inefficient for the whole site.
+4
A:
There's a distinction to make here: PHP is not a web server. Therefore, the end of a PHP script is irrelevant to the actual end of the web server (or at least, most of the time).
Web server software that continuously run, like IIS, Apache or Lighttpd can execute PHP scripts without ending themselves. These scripts, at the end, do cease to run. How web servers set up the execution environment for the script depends on the approaches taken. For instance, Apache 2 can indeed spawn a child process for each web request, though it does not set up again the whole web server each time: there's a master process that commands the children about execution settings and parameters.
Therefore, a PHP script ends when the web request ends; that is, when the script reaches a statement that makes it stop (like a fatal error, an exit statement or the like) or when it reaches the actual end of the script source.
EDIT About the efficiency of spawning a new process for new requests.
Nowadays, servers don't spawn a separate process for PHP itself: they use the PHP library to embed the language and work with it. However, servers are indeed free to spawn a process for every HTTP request they receive. Apache does it with its mpm_prefork module.
While spawning a new process is indeed expensive, it's potentially nothing when compared to the cost of the script itself, which can last tenths of seconds, which is much, much more than just spawning a process.
Also, servers usually have to serve many clients at once; therefore, it is unthinkable to just treat every request sequentially. They must be run concurrently, and that leaves implementors two options: threads or processes. PHP not being thread-safe on many platforms, it is often preferable to run it in a separate process.
zneak
2010-04-20 23:16:07
Similar to printing: your output outlasts its creator.
drewk
2010-04-20 23:17:12
ASP.NET is not a webserver itself too. In spite of this it runs continuously.
zerkms
2010-04-20 23:17:35
@zerkms: Yeah, I know.
zneak
2010-04-20 23:25:03
Apache spawns a separate process to handle each request, no?
intuited
2010-04-20 23:26:27
@intuited: it's 2 different mpms out of box (mpm_worker and mpm_prefork). Plus as alternative you could look at PHP-FPM too.
zerkms
2010-04-20 23:28:45
@intuited: older versions of httpd had a processes pool to handle requests. A request is handed off to an existing process; if there were too many outstanding requests, new processes are launched, up to a limit. Newer versions can use threads rather than processes, but the rest is basically the same.
outis
2010-04-20 23:31:15
@zerkms: I don't understand what confuses you. What should I say to improve my message?
zneak
2010-04-20 23:33:52
@zneak: i have understood you in wrong way, all is fine. sorry.
zerkms
2010-04-20 23:36:35
@zerkms, @outis: is it possible to use `mod_php` with `mpm_worker`? The Ubuntu `libapache2-mod-php5` package requires either `mpm_prefork` or `mpm_itk`: "Please note that this package ONLY works with Apache's prefork MPM, as it is not compiled thread-safe."
intuited
2010-04-21 05:43:07
@intuited: a Google search suggests mod_php isn't thread safe (depending on which extensions you use), and thus isn't suitable to use with mpm_worker. Why do you ask? Even if you use a resident version of PHP (such as with mpm_prefork or fastCGI), the scripts themselves will exit upon completion. Furthermore, relatively few types will persist across script invocations (persistent SQL connections are the only thing that come to mind).
outis
2010-04-22 07:29:31
If mpm_worker could be used it would be less expensive to fork a new instance right? Ie startup overhead per PHP request would be minimized? I'm booked to go ahead a couple years in the future tomorrow; conceivably all of the standard extensions could be threadsafe by then. Sorry, they never tell me this stuff in advance. Anyway it's like kind of neat and stoff [sic].
intuited
2010-04-22 16:48:26
@zneak: Thanks. I understand the difference between the web server and PHP processes. My confusion is over whether there is a new PHP process for each web request. If so, wouldn't that be terribly inefficient? My understanding is that it's fairly expensive to spin up a whole new process, an activity that the OS is in charge of. As I understand it, this is the whole reason that CGI has fallen out of favor, and would never be used for a serious website.
allyourcode
2010-04-22 23:07:12
@allyourcode: I edited my message to include a few reasons for spawning a process for each request.
zneak
2010-04-22 23:17:04
@intuited: for efficiency's sake, it sure would be nice if mod_php worked with mpm_worker (however, see http://www.complich8.net/archives/404).
outis
2010-04-24 10:43:45
@intuited, @allyourcode: you can run the FastCGI version of PHP rather than as an Apache module. FastCGI runs external interpreters in a managed pool of processes, rather like Apache does to handle requests.
outis
2010-04-24 10:55:09
+2
A:
Yep, this is what actually happened, each request. This is the nature of PHP.
zerkms
2010-04-20 23:16:26