And just to throw one more wrench into the works. You could load up only the most popular data at startup and let the rest of the data get loaded on a cache miss.
That is one technique that we have used for some customer session servers. It allowed each server to start up in well under a minute instead of in 15-30 minutes while pegging the DB. The 15-30 minutes was when we were dealing with ~5mil total entries and I would hate to see it now that the size of the table has doubled. Now we just need to do some batch processing to determine what subset gets loaded at startup. Ian On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote: > 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 > > > > > > > > > >
