RE: [cgiapp] RFC: CGI::Application::Plugin::CAPTCHA

["Dan Horne" <suppressed>]

It would be nice if whatever solution is selected can run under Windows too.
Many memory-based caching systems are specific to *nix systems and don't
work with MS (particularly the IPC ones). What about supporting the
Cache::Cache API, and then  let the developers choose which Cache::* module
suits?.

Dan

> -----Original Message-----
> From: Cees Hek [mailto:suppressed 
> Sent: Saturday, 27 August 2005 02:33
> To: Michael Peters
> Cc: suppressed
> Subject: Re: [cgiapp] RFC: CGI::Application::Plugin::CAPTCHA
> 
> 
> 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
> 
> 


---------------------------------------------------------------------
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