Re: [Speedycgi-users] Memory leak in speedy_backend

[Sam H. <sa...@da...>]

Using links shouldn't affect the environment variables.

 > Thank you for your feedback, Sam. Actually, I just discovered that I am 
 > in fact already using SpeedyCGI v2.21, not v2.11, since last October 
 > 2002. And yes, all domains run under the same Apache user id. I applied 
 > your hint to "use" instead of "require" modules, as well as to preload 
 > the entire utilized module set in the main application. However, the 
 > described behavior in terms of memory growth and excessive port 
 > connections remains the same.
 > 
 > The idea to hard/soft link the application is interesting, however, will 
 > this strategy preserve the ENV vars of each virtual host (which the app 
 > depends on to distinguish between the hosts)? If yes, this might be the 
 > route to take.
 > 
 > Thanks -- Ph. Wiede
 > 
 > 
 > Sam Horrocks wrote:
 > > Groups help when you have many different scripts that you want to run
 > > within a single interpreter.  If your only concern is a single cgi-bin
 > > script, groups won't make a difference.  But using groups won't hurt,
 > > as long as your code is OK running that way.
 > > 
 > > In addition:
 > >     - Make sure all the domains run under the same user id.
 > > 
 > >     - Make sure all domains use the same exact file.  If you have multiple
 > >       copies of the script (for example one copy per virtual host), it
 > >       wont work right - each copy will have a different inode in the
 > >       filesystem, and therefore its own package (with groups),
 > >       or its own interpreter (without groups).  If you need to put the
 > >       same script in multiple locations, make sure to use links (hard or
 > >       soft) instead of copying the file.
 > > 
 > >     - As much as possible use "use" instead of "require" to load modules.
 > > 
 > >     - If your application involves multiple scripts in a single group,
 > >       make sure that all scripts "use" all the modules that the scripts
 > >       in that group will need.  That way no matter which script is started
 > >       first, the interpreter will compile into the parent all the
 > >       modules that group will need.
 > > 
 > >     - Upgrade to the latest version - there is more sharing of compiled code
 > >       in 2.20 and later, and there is better control on the number of
 > >       backends spawned.
 > > 
 > > 
 > > 
 > > 
 > >  > Thanks for taking the time to reply, Sam. I'm using the speedycgi apache=20
 > >  > module v2.11 with Apache/1.3.23 (Unix).
 > >  >  > As to the socket connections, with netstat -a the UDP connections are=20
 > >  > shown to be caused by the HTTPD process. There are around 100 virtual=20
 > >  > hosts.
 > >  >  > As I said the memory leaks are caused by the speedy childs not the=20
 > >  > backend. I have found the cause by now, it's not a leak but seems to be=20
 > >  > my misunderstanding of the group feature. Say, I have 10 domains running=20
 > >  > the same Perl application (named for this example "Tracker", utilizing=20
 > >  > identical modules) each out of their CGI-BIN, using the same speedycgi=20
 > >  > group id. Tracker's persistent vars are initiated only if undefined, as=20
 > >  > is a database sizing 3 MB that is then loaded into memory. So the domain=20
 > >  > that is first accessed launches Tracker and the speedycgi backend via a=20
 > >  > SSI call. This works as  documented - one backend, one child process=20
 > >  > (ore more depending on traffic).
 > >  >  > But my understanding was that the loaded speedycgi backend would treat=20
 > >  > all Trackers with the same group id as one application across all=20
 > >  > virtual hosts. Unfortunately, this is not the case as speedycgi seems to=20
 > >  > treat each domain's Tracker as an unique application in terms of=20
 > >  > Namespace and variables. The supposed "memory leak" is just caused by=20
 > >  > each domain's Tracker loading its own static vars and database instead=20
 > >  > of this being done once and globally by the first launched Tracker.
 > >  >  > Why is this so? How can one preload a set of modules to be reused by=20
 > >  > applications sharing the same group id? Or is this feature not=20
 > >  > implemented (yet :)?
 > >  >  >  > Thanks -- Ph. Wiede
 > 
 > 
 > 
 > -------------------------------------------------------
 > This SF.net email is sponsored by: SF.net Giveback Program.
 > SourceForge.net hosts over 70,000 Open Source Projects.
 > See the people who have HELPED US provide better services:
 > Click here: http://sourceforge.net/supporters.php
 > _______________________________________________
 > Speedycgi-users mailing list
 > Spe...@li...
 > https://lists.sourceforge.net/lists/listinfo/speedycgi-users
 >