3 ms·

Is one process per user still viable? It sounds like it would not scale / not work well with cloud deployments.

by wozer 6y ago

tlb 6y ago
For Viaweb, users (ie, e-commerce sellers) paid $100+ per month. So a process per user isn't expensive. Shoppers didn't require so much state (just a shopping cart) so that part of the system kept all the state in a sharded database. There is some routing infrastructure required by the front end to route requests, time out after inactivity, and reload the process if they come back. But it can give very snappy response to have all the data needed to serve a request all loaded in memory.
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 ago
  It 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 ago
    The 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.

Is one process per user still viable? It sounds like it would not scale / not work well with cloud deployments.

by wozer 6y ago

Is one process per user still viable? It sounds like it would not scale / not work well with cloud deployments.

tlb 6y ago

For Viaweb, users (ie, e-commerce sellers) paid $100+ per month. So a process per user isn't expensive. Shoppers didn't require so much state (just a shopping cart) so that part of the system kept all the state in a sharded database. There is some routing infrastructure required by the front end to route requests, time out after inactivity, and reload the process if they come back. But it can give very snappy response to have all the data needed to serve a request all loaded in memory.

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 ago
It 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 ago
  The 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.