--- Alvar Freude <[EMAIL PROTECTED]> wrote: > > My Problem is, that I need about 100 MB data persistant in RAM for > fast > hash access. At the moment I do this by building the hash at Apache > startup, and all is shared between the childs. But sometimes there > are > changes ... and then Copy-on-Write un-shares the data and the Apache > eats > more and more memory ;-) > > My idea is to write a daemon (using forks.pm) which can be connected > by > the mod_perl part; on updates, I shut down all children of the daemon > and > restart them (as needed). > > > So the next idea is, that the mod_perl app can talk directly to the > worker childs. But as more as I think about this, this seems to be > nod > good idea and more complicated then sending some freezed commands > over a > socket ... >
If you are using mod_perl 1.0, or mod_perl 2.0 with the 'prefork' MPM, I have successfully worked with a few companies to integrate forks into Apache httpd instances. Additionally, if you use the forks::BerkeleyDB add-on, you'll get excellent shared variable access performance (which sounds like a requirement for your 100MB of data). This data doesn't depend on fork COW to share between apps, so it's safe to update it during runtime without incurring memory penalties (and updates are also visible immediately between all apache handlers and extra threads you may start in the mod_perl environment). I've almost finalized an Apache::forks module to seamlessly integrate forks into an Apache httpd environment. So far, results are very promising: solid memory and application stability, and performance is quite satisfactory. I haven't yet posted Apache::forks to CPAN, but if you're interested in evaluating it, I'll be happy to e-mail you a stable pre-release that works with forks 0.23 and forks::BerkeleyDB 0.05. Regards, Eric Rybski
