On 9/6/07, David Willams <[EMAIL PROTECTED]> wrote:
> When the translation happens on a random, ad hoc string of sometimes
> thousands of "words", the process simply does something like this:
>
> Untranslated:
> hfj kei hty ... jan oej wio
>
> Translated:
> $CACHE{hfj} $CACHE{kei} $CACHE{hty} ... $CACHE{jan} $CACHE{oej}
> $CACHE{wio}
Well, there's nothing that can come even close to the speed of an
in-process perl hash, so if you really need it be that fast, you will
have to reload the hash when the data changes. There are various
strategies for this: restart your server periodically (you can use
proxy tricks to avoid downtime), load a local hash of just the stuff
changed recently in each process and use it as an overlay (two lookups
will still be much faster than any out-of-process storage).
If you don't need quite that much speed, a simple read-only approach
with BerkeleyDB or SDBM file will still be very fast. You can write
out the files from a cron job every few minutes with sequentially
numbered names, and the mod_perl processes can check periodically to
make sure they're reading the latest one. Since the mod_perl
processes only read it, they can open it and just keep the handle open
in a global.
Don't use either of the Cache::* modules I mentioned unless you don't
mind doing a secondary lookup in your RDBMS for keys that aren't found
in the cache. They both silently drop data when they run out of
space.
- Perrin
