3 ms·
Not viable for handling many users at once on a single unix box, no. Context switching between the processes starts to dominate your time. It’s an old-school ap
by spenczar5 6y ago
Not viable for handling many users at once on a single unix box, no. Context switching between the processes starts to dominate your time. It’s an old-school approach that is really tidy at relatively low concurrency.
In the early 2000s, this area was sometimes called the “C10k problem” - can you handle 10,000 concurrent connections on one machine? See https://en.m.wikipedia.org/wiki/C10k_problem https://en.m.wikipedia.org/wiki/C10k_problem
These days, most servers can blow way past that, even into millions, but none - that I am aware - do that with a process-per-connection model.
- tannhaeuser 6y agoIt depends. If you're caching ("weakly" eg with revalidating If-Modified-Since against mtime, or even "strongly" eg aggressively), which you should, you're creating processes only for a small fraction of requests. Remaining major overhead is reparsing dynamic language backend code, which you can further reduce by using native code.
- spenczar5 6y agoThe cache is served by an HTTP server still, though. What you are describing is a sort of hybrid, where most requests are handled in threads (either OS or green threads) but a small fraction get their own process. I think I agree that that could work, but it sounds a bit different from creating a process per connection. I don’t think parsing code is the major overhead. Its not really about starting the processes so much as switching between them when concurrently handling a bunch of requests.