3 ms·

It's very similar to that setup. I don't think that was particularly common though and probably the reason prefork went away. Particularly as apache and later n

It's very similar to that setup. I don't think that was particularly common though and probably the reason prefork went away. Particularly as apache and later nginx were used as the user facing webservers proxying to something else inside (first with fastcgi and latter just http). The preforking advantage then moved to that server inside which is what this is. Nginx or something similar will still be running in front of this with a threading or event model instead of forking. So this is not going back to an old idea as it never really left, it just left apache because no one ran it as an application server and there are better ways to run an http frontend. Preforking is also not what's new here, this is just an optimization over the preforking model in unicorn which is over a decade old.

a-dub 4y ago
it went away because it was resource expensive. even with copy-on-write semantics, those backend httpds with an entire perl runtime in each core were pretty huge and inefficient. the models that replaced it were single process multiple threads and asynchronous (never block) models that didn't create or require one of many application processes per request. i think the choice of the preforking model was a stability and portability thing. if one of the children crashed it was no big deal, where a crash in a single process application or webserver will cause the everything to go down. also back in those days threading semantics varied widely between operating systems, the apis themselves differed and linuxthreads were just really too new to run in production.
- pedrocr 4y ago
  But it didn't go away. Event based servers were developed to handle slow clients with good performance as frontends for pre-fork or threaded application servers. This innovation is an optimization of a pre-fork backend server that itself is almost 15 years old.

a-dub 4y ago

it went away because it was resource expensive. even with copy-on-write semantics, those backend httpds with an entire perl runtime in each core were pretty huge and inefficient. the models that replaced it were single process multiple threads and asynchronous (never block) models that didn't create or require one of many application processes per request. i think the choice of the preforking model was a stability and portability thing. if one of the children crashed it was no big deal, where a crash in a single process application or webserver will cause the everything to go down. also back in those days threading semantics varied widely between operating systems, the apis themselves differed and linuxthreads were just really too new to run in production.

pedrocr 4y ago
But it didn't go away. Event based servers were developed to handle slow clients with good performance as frontends for pre-fork or threaded application servers. This innovation is an optimization of a pre-fork backend server that itself is almost 15 years old.