I havent had much luck with that but we will look at it again and see what we can get from it. We want to avoid preloading all data per child direct from the database but I wouldnt mind doing it on startup for the root process and then copying it to each child.
J On Tue, 20 Aug 2002 16:39:45 -0500 [EMAIL PROTECTED] wrote: >Just to jump in here - as I understand it you can split a >hash across >multiple threads if you preload it before apache forks. >So load it in your >startup.pl and get it in memory prior to forking. It'll >be part of the >shared memory since you aren't writing to it. Or at least >that's how I >understand the theory to work anyway. > >Josh > > > > ><[EMAIL PROTECTED]> >08/20/2002 10:54 AM > > > To: Tony Bowden <[EMAIL PROTECTED]>, md ><[EMAIL PROTECTED]> > cc: Perrin Harkins <[EMAIL PROTECTED]>, >[EMAIL PROTECTED] > Subject: Re: Apache::Session - What goes >in session? > > >We do see some slowdown on our langauge translation db >calls since they are so intensive. Moving to a 'per >child' >cache for each string as it came out of the db sped page >loads up from 4.5 seconds to .6-1.0 seconds per page >which >is significant. > >Currently we are working on a 'per machine' cache so all >children can benefit for each childs initial database >read >of the translated string, the differential between >children is annoying in the 'per child cache' strategy. > >John- > >On Tue, 20 Aug 2002 16:33:07 +0100 > Tony Bowden <[EMAIL PROTECTED]> wrote: >>On Mon, Aug 19, 2002 at 06:54:01PM -0700, md wrote: >>> I can definitely get it all from the db, but that >>>doesn't >>> seem very efficient. >> >>Don't worry about whether it *seems* efficient. Do it >>right, and then >>worry about how to speed that up - if, and only if, it's >>too slow. >> >>Premature optimisation is the root of all evil, and all >>that .. >> >>At BlackStar the session was just a single hashed ID and >>all other info >>was loaded from the database every time. We thought about >>caching some >>info a few times, but always ran into problems with >>replication. In the >>end we discovered that fetching everything from the >>database on every >>request wasn't noticeably slower than anything else we >>could up with, >>and was a lot more flexible. Throwing more memory at the >>database servers >>was usually quicker, cheaper and more effective than >>micro-optimising >>our session vs caching strategy... >> >>Tony > > > >
