This is a discussion on Re: mod_perl using IPC::ShareLite - modperl ; may be the linux ramdisk is another good choice. you can use memory like normal filesystem. ----- Original Message ----- From: "Frank Wiles" To: Cc: Sent: Wednesday, September 27, 2006 9:45 PM Subject: Re: mod_perl using IPC::ShareLite > On Wed, ...
may be the linux ramdisk is another good choice.
you can use memory like normal filesystem.
----- Original Message -----
From: "Frank Wiles"
Sent: Wednesday, September 27, 2006 9:45 PM
Subject: Re: mod_perl using IPC::ShareLite
> On Wed, 27 Sep 2006 13:13:51 +0100
> "Ben Wilder"
> > My research so far has led me to believe that IPC::ShareLite could be
> > used by the cron job script to set a few (very small) variables into
> > a portion of shared memory, that a separate mod_perl application
> > could poll. Mod_perl would not need to modify these variables, only
> > read them.
> > Would using a library such as IPC::ShareLite be considered a fudge
> > for this type of action, is there some sort of global apache variable
> > section that I can modify with one application and read out from
> > another?
> > Any thoughts appreciated!
> Using one of the IPC modules is definitely a reasonable choice
> based on what you're trying to do. But I wanted to throw out
> some other options as some people find IPC hard to work with.
> 1. BerkeleyDB or sqlite. I realize you said you'd like to avoid a
> database, but sometimes this means avoid installing a big
> RDMS like PostgreSQL, MySQL, etc.
> 2. memcached and Cache::Memcached could store your data in
> a memory cache for you.
> 3. Use can also use a simple config file with something like
> Config::General. Your crons can update this data onto disk
> and your mod_perl apps can simply read it in as a config file,
> maybe using a short 5 minute cache to reduce disk reads.
> 4. You could also use Storable to drop an object full of your
> small variables from your cron and have your mod_perl app
> read them in on each request ( or a short cache in pnotes or
> something ).
> The last two may sound slow due to the disk reads, but it really
> shouldn't cause a performance problem in all but the most
> demanding environments.
> Frank Wiles