Yeah, its a general problem with preforking servers. Really Apache probably SHOULD run as a single multi-threaded application itself ideally. 2.0 is moving in that direction.
On Monday 24 November 2003 11:14 am, Ken Burcham wrote: > Thanks for the explanation... So there isn't really any concept of an > overall "application", but rather just threads of processing that flow > through the childrenservers... So each request runs in its own thread > in an arbitrary childserver so there isn't a place to cache stuff in > memory... > > I think for what we're doing, I can simplify the creation of the objects > and then not cache them at all. So far, caching provides a 50% gain. > But it has been unreliable as to what I get out and now I see why. :) > > Ken. > > -----Original Message----- > From: Tod Harter [mailto:[EMAIL PROTECTED] > Sent: Friday, November 21, 2003 7:56 PM > To: [EMAIL PROTECTED] > Subject: Re: lifecycle and variable question > > Well, this question is best answered by understanding the processing > model > used by Apache, preforking. When Apache starts up the master process > first > processes the httpd.conf file. At this point there is one copy of Apache > and > mod_perl in existence. The only way you can run anything at this point > is to > put code in a file included with PerlRequire or PerlModule directives > (or > inside a <perl> section). > > Once Apache has finished initializing it then forks MinSpareServers > children. > Each of these children now has an exact clone of the perl environment as > it > was at that moment. At this point each child calls any > PerlChildInitHandler > which has been declared. > > As requests are received the main apache process hands them off to any > child > which happens to be idle (and may create and destroy children as needed, > > always forking them from itself). > > Thus the environment is that you will have several copies of mod_perl, > each > randomly handling a subset of all page requests, and each with a > completely > separate set of variables! Thus if you create a global hash at startup > time > (say in a PerlRequire'd module) every child will see that hash, in > exactly > that state, the FIRST time it handles a request. Any changes a child > makes > will ONLY be visible to that child. > > So if you do as you say and create a hash to use as an object cache, > then each > child will fill its copy with different objects. This is OK if you only > READ > from the cache, but every time an object is WRITTEN you will need to > flush it > back to the backing store (database), and furthermore you would need to > invalidate that object in EVERY child's version of the cache. This IS > possible using IPC (shared memory, etc) but the truth is it simply isn't > > worth it. In-memory object caches in mod_perl are for the birds. > > Now, maybe with mod_perl 2 on Apache2 with a multi-threaded MPM and > assuming > we get 'solar variables' it would be possible to use in-memory object > caches > in a practical way, but then your code will be horribly non-portable > since it > would only work in one MPM (IE, it might work on Win2k server, but not > on > Linux in general). > > On Thursday 20 November 2003 1:58 pm, Ken Burcham wrote: > > Hi there, > > > > I'm a little unclear on the lifecycle of things with axkit, mod_perl > > and the like. For example, if in an xsp I look at a local file using > > XML::Simple to grab some configuration information (like location of a > > log4perl config file, server name, etc) can I do that lookup just once > > and stuff it somewhere like an application server variable? Or is > > that > > > type of information better suited somewhere else (httpd.conf?). Or > > does > > > my xsp have to look that info up every time it is called? > > > > Also, (and maybe this is just a simple perl question) if I have a > > perl > > > package like the following: > > > > package some::package; > > > > my %cacheofobjects = {}; > > > > sub add2cache > > { > > my $this = shift; > > my $obj = shift; > > my $name = $obj->name; > > $cacheofobjects{$name} = $obj; > > } > > > > sub getfromcache > > { > > my $this=shift; > > my $name = shift; > > return ($cacheofobjects{$name}); > > } > > > > that my xsp uses to cache objects between hits, where does this cache > > live? Or does it? I'm afraid I don't understand the lifecycle of > > perl > > > objects esp in the context of axkit. Thanks in advance for your help! > > > > Ken. -- Tod Harter Giant Electronic Brain http://www.giantelectronicbrain.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
