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
