4 ms·

He seems to recognize (correctly) that Apache's mpm idiom is crap, but he still seems to think that its model of loading multiple language runtimes into one mon

by blasdel 17y ago

He seems to recognize (correctly) that Apache's mpm idiom is crap, but he still seems to think that its model of loading multiple language runtimes into one monolithic process is a good idea. Why does it matter if you use 4 or 8 event-handling processes on one machine, each with their own database connection? If that's your scaling bottleneck, you'd be running on many machines anyway, so a small constant multiplier doesn't change the story. Besides, you could use crap like ODBC to have one persistent DB connection per machine.

jacquesm 17y ago
I'm with you on the multiple language runtimes into one process, I find it hard to envision a situation where that would be a benefit, the only situations I can think of have nothing to do with scaling issues (multiple smaller websites for some reason bound to legacy versions of an interpreter). The other issue (a small number of processes accepting work) is a good idea though I think, to get the number of processes doing actual work closer to the number of cores. After all, even if it is a 'small multiple' it is a divider when it comes to how much hardware you need and less hardware=better. The DB may be a bottleneck, it may not be, that very much depends on the workload of the server.
- blasdel 17y ago
  But he's arguing against the idea of having a small number of processes -- he seems to want a single monolithic process per machine, with a native threadpool and multiple interpreters to get around GILs. The idea of rolling multiple interpreters into a single process is especially bad for python, as it has a real garbage collector and os.fork()-ed processes will share a lot of memory. It makes some sense for Ruby, since its assy mark-and-sweep will invalidate every single page on the next collection after a fork().
  - audidude 17y ago
    I tried to argue that was an implementation detail with sacrifices no matter which direction you go. One could also argue that its problematic to deal with run-away runtimes with memory issues. The GC does provide an interesting problem I didn't consider. Especially those that over-utilize OS signals. Perhaps the choice of Python was poor for this. You can still separate it into two fundamental shifts. The first being making a fully asynchronous/event driven module/handler API. This should be done regardless of the runtime module. The massively-scaled websites I've seen would tip with 4-8 times the sql connections. SQL Server is especially bad at this. It also makes it hard to simply throw additional hardware at the problem. I guess you could yield on resources from a master process if you have the logic to know their status.
    - peoplerock 17y ago
      @audidude: FYI - your server (www.audidude.com) is either being hit really hard right now or is completely down. Without access to the original post there, this noob can only assume(hope) the discussion is about the Tornado Web Server (http://www.tornadoweb.org/ http://www.tornadoweb.org/). I'm interested in alternatives to Apache, so am looking forward to you being back online. Gracias.
paul 17y ago
Exactly. Stuffing everything into one process is a whole lot of complication for very little benefit.

by blasdel 17y ago

jacquesm 17y ago

I'm with you on the multiple language runtimes into one process, I find it hard to envision a situation where that would be a benefit, the only situations I can think of have nothing to do with scaling issues (multiple smaller websites for some reason bound to legacy versions of an interpreter). The other issue (a small number of processes accepting work) is a good idea though I think, to get the number of processes doing actual work closer to the number of cores. After all, even if it is a 'small multiple' it is a divider when it comes to how much hardware you need and less hardware=better. The DB may be a bottleneck, it may not be, that very much depends on the workload of the server.

blasdel 17y ago
But he's arguing against the idea of having a small number of processes -- he seems to want a single monolithic process per machine, with a native threadpool and multiple interpreters to get around GILs. The idea of rolling multiple interpreters into a single process is especially bad for python, as it has a real garbage collector and os.fork()-ed processes will share a lot of memory. It makes some sense for Ruby, since its assy mark-and-sweep will invalidate every single page on the next collection after a fork().
- audidude 17y ago
  I tried to argue that was an implementation detail with sacrifices no matter which direction you go. One could also argue that its problematic to deal with run-away runtimes with memory issues. The GC does provide an interesting problem I didn't consider. Especially those that over-utilize OS signals. Perhaps the choice of Python was poor for this. You can still separate it into two fundamental shifts. The first being making a fully asynchronous/event driven module/handler API. This should be done regardless of the runtime module. The massively-scaled websites I've seen would tip with 4-8 times the sql connections. SQL Server is especially bad at this. It also makes it hard to simply throw additional hardware at the problem. I guess you could yield on resources from a master process if you have the logic to know their status.
  - peoplerock 17y ago
    @audidude: FYI - your server (www.audidude.com) is either being hit really hard right now or is completely down. Without access to the original post there, this noob can only assume(hope) the discussion is about the Tornado Web Server (http://www.tornadoweb.org/ http://www.tornadoweb.org/). I'm interested in alternatives to Apache, so am looking forward to you being back online. Gracias.

paul 17y ago

Exactly. Stuffing everything into one process is a whole lot of complication for very little benefit.