On Thu, Jul 18, 2013 at 9:15 AM, Massimo Manghi <massimo.man...@unipr.it>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
