On 8/26/05, Michael Peters <suppressed> wrote:
> Caching is basically just storing information that just needs to be
> calculated once but potentially used over and over. It usually resembles
> a hash with keys and values. The keys usually represent the arguments
> used in the calculation and the values are the cached results.
>
> My collegue, Perrin Harkins, has done quite a lot of work and
> comparisons of the various Perl cacheing options and I have to say that
> Cache::Cache is his least favorite. It's pretty slow. He usually
> recommends the following:
>
> Cache::Memcached - it's the fastest but does require another daemon
> (memcached) to be running.
>
> MySQL - For simple primary key (unique hash key) look ups it's extremely
> fast, but again it requires an external program, although it's more
> common than memcached.
>
> BerkeleyDB - No external daemon need and still almost as fast as the
> other 2 (look at BerkeleyDB and BerkeleyDB::Lite)
This covers the 'long lived' caches which usually include the file
system. I also sometimes use very small and simple in memory caches
as well. It really depends on your requirements.
For in memory caches, you should stay away from using shared memory
(IPC) since surprisingly, on modern systems it is usually faster to
use the filesystem (with one of the options Michael lists above).
All you need for a simple in memory cache is just a global variable in
your code somewhere that holds some of the values that you need most
often.
An easy way to keep the most used values in your cache without using
up too much memory is to use something like Tie::Cache::LRU. I
dislike tied variables, but in this instance it can be useful
tie %cache, 'Tie::Cache::LRU', 100;
That gives you a hash that will only keep a max of 100 elements, and
drop off the least recently used item when you overflow the hash.
There are some drawbacks to this system...
- It is only useful in persistent environments
- The cache is not shared, so when using it under something like
mod_perl, you will have a different cache with different values in
each apache child process
- You can have issues with stale data, since the same value can be
cached in multiple Apache Child processes, so if it gets updated in
one location, the other locations will not see the update if they keep
pulling the info out of the cache
- The cache will not survive a restart.
So if you can live with those drawbacks, and only have small bits of
data to cache, then an in memory cache may work for you. In most
instances though, the solutions Michael list above are going to work
better for you.
Cheers,
Cees
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/suppressed/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.