3 ms·

That was only forking the apache process. This is forking the whole ruby app that also happens to speak HTTP. The gain is in the app side not in the best way to

That was only forking the apache process. This is forking the whole ruby app that also happens to speak HTTP. The gain is in the app side not in the best way to serve HTTP where this is probably a loss over threading or event based solutions.

a-dub 4y ago
many serious applications back then built by developers who cared about performance and latency made use of mod_perl. it put the entire perl interpreter (which then loaded perl modules that defined the application) into the preforked apache httpd processes. often times you'd put a proxy in front, serving static assets with a lighter weight http so that slow loads wouldn't tax limited server capacity for big httpd processes that included full perl interpreters and all application code loaded. so it seems it's almost exactly the same?
- pedrocr 4y ago
  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

many serious applications back then built by developers who cared about performance and latency made use of mod_perl. it put the entire perl interpreter (which then loaded perl modules that defined the application) into the preforked apache httpd processes. often times you'd put a proxy in front, serving static assets with a lighter weight http so that slow loads wouldn't tax limited server capacity for big httpd processes that included full perl interpreters and all application code loaded. so it seems it's almost exactly the same?

pedrocr 4y ago
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.