Using the event MPM with a non-threaded Tcl works fine. That's what I use just because it's the default in most cases, so I had never hit the issue being discussed. When I recently built a new server, I tried a threaded Tcl with prefork (as our docs say) and hit it. When I compiled back to event / non-threaded, everything works.
Not saying that's an answer, just throwing in my experience. I also use SeparateVirtualInterps as I generally run a bunch of smaller sites on a single instance. I know FA and other bigger users are not going to have that turned on. D On Jul 18, 2013, at 11:43 AM, Jeff Lawson <[email protected]> wrote: > > > > On Thu, Jul 18, 2013 at 9:15 AM, Massimo Manghi <[email protected]> > wrote: > On 07/18/2013 08:39 AM, Harald Oehlmann wrote: > > > > I have reasoned the requirement by the fact, that the following feature > > saved 40 minuites of boot time for FlightAware (what I think I have read > > here): > > > > - Start master interpreter > > - source packages > > - fork a client interpreter > > - open data base connections etc. > > > > If not so, we should revert this, and just do all of that after the fork. > > > > I'd like to hear from the FA guys on this. FWIK they had a tremendous > improvement in the startup of their application. > > This feature has some limitation though, even when you are not demanding > the notifier to be working. Slave interpreters generation don't > propagate the packages initialization to slave interpreters, therefore > if SeparateVirtualInterps is on you cannot share among virtual hosts a > common ground of preloaded packages. (Would this be worth a TIP > requiring to extend the slave interpreter command to support initialization) > > > It is definitely important for us at FlightAware to be able to do Tcl > interpreter initialization before forking. Our webserver environment uses > multiple physical servers each with 300 Apache children processes. During > the Tcl global init and before forking, we pre-load several gigabytes of > infrequently changed data from our database for performance. > > The inability to do this pre-loading would cause each child to have to load > this data from the database (which causes a massive database overhead for 300 > connections to simultaneously request that much data), which indeed adds many > minutes of startup time to our daily release cycle. Since our release cycle > requires us to fully restart one physical server at a time so that we can > continue to serve production traffic on the remaining physical servers, any > increase in restart time cascades linearly with the number of physical > servers we have. > > The added database overhead of these 300 Apache children requesting gigabytes > of data would also compromise our ability to handle normal database traffic > from our other servers while we are restarting one. > > Additionally, the RAM usage on the webservers is significantly impacted since > this static data is now actually allocated and duplicated in each child, > rather than being loaded in the parent and cloned via copy-on-write pages to > each child. Several gigabyte per child multiplied by 300 processes is a > significant memory footprint change for our webservers. > > > Jeff
