Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know CGI spawns a new process for every HTTP request that it serves, while servlets use one Java process to serve many requests. What do other technologies (rails, WSGI/django, mod_php, etc.) do so that web servers do not have to spawn a new process new HTTP request?

share|improve this question

closed as too broad by gnat, MichaelT, GlenH7, Kilian Foth, jwenting Nov 6 '14 at 12:24

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

If I'm not mistaken mod_php does spawn a new PHP interpreter process for every request. In any case, FastCGI is a common solution to the problems of CGI. Rails can use FastCGI, but more common is to serve it through Thin, Passenger, Unicorn, Mongrel, or similar services that keep long-running application processes in memory that handle many requests over their lifetime. – Ben Lee Apr 9 '12 at 20:02
Since mod_php is an Apache module it does indeed spawn a new PHP interpreter for every request. This is actually a huge part of the reason why FastCGI uses so much less memory for PHP installs, the PHP interpreter is only spawned one time as compared to every request. – cspray May 12 '12 at 5:24
In ASP.NET there is a separate thread for each request. In windows threads are expensive too so it relies on the .net thread pool to manage the threads. – Bond May 18 '12 at 11:26
up vote 1 down vote accepted

Servers generally either

1) Use a thread pool with a thread per client connection request, potentially with a separate pool of separate thread/processes to handle "application" code (as opposed to the basics of handling a HTTP request. A thread handles each request from beginning to end; often thread pooling is used to reduce the amount of startup and teardown required with each connection.

Or, 2) they will use an event-based model which allows a single thread / process to handle many connections. In this case, each of the "events" such as new connection or new received packet will go into a queue of sorts to be worked through by one or a small number of threads. This is a highly efficient way to scale if you can limit the amount of work to be done processing each event (otherwise small quick requests will be queued behind larger requests).

The major difference as far as outcomes are concerned is that both of these models avoid or minimise the overheads of process startup time and inter-process communication and handoffs.

share|improve this answer

In general, what happens is that servers pool threads to support multiple connections. Once the connection is released, the thread is returned to the pool to be used by the next connection. Now the details of this is different for most things. Thinking about what happens to make this work well, systems will open up a process and reuse it to handle multiple requests once it's returned to the pool.

App Servers bundled inside the web server (ASP.NET, Tomcat) don't have to worry about executing external processes because they built on the assumption that your code will handle threading correctly. When talking about Ruby on Rails for instance, most things are not thread safe. Reuse within in the same process would likely lead to undesirable results. (For rails, at least on JRuby, this likely less of the problem it once was.)

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.