As far as the cacheing goes, we have had extremely good luck with IPC::ShareLite used to share info across mod_perl processes.
--Jon R. Chip Turner wrote: > > "Bruce W. Hoylman" <[EMAIL PROTECTED]> writes: > > > Ciao! > > > > I would like some input on an intranet web service I am currently in the > > process of designing, the core of which will be modperl on UN*X. > > Excellent choice. This works quite well. Of course, like others on > this list, I might be a bit biased. > > > The service itself is to access a couple of back end data stores given > > parameters received in an XML-RPC request, then return the results in an > > XML-RPC formated response. The data from the back end sources will be > > loaded into memory at service initialization, for fast access. The data > > is small enough and memory plentiful enough to allow this. > > How often does the data change? How is it stored on the back end? > You may not need to cache anything if, say, you have a decent SQL > database on the backend. Caching never hurts, but it isn't always > necessary. The Cache::* modules may be of use for this, though, > should you still need it. You also might want to consider not sharing > the data in each process; the complexity gained vs the memory lost by > storing it in each process may be a workable tradeoff. I probably > would try it first with no cache, then a per-process on-demand cache, > then finally a shared cache, in that order. > > > That's pretty much it in terms of the high level data flow. It has to > > be relatively fast, OTO 5+ requests/sec. as a relative volumetric. > > This should be quite easy. I don't have the necessary setup handy to > benchmark it, but I imagine you can easily achieve performance at that > level using Frontier::RPC inside a mod_perl handler. We typically use > custom code for interfacing the handler, but IIRC the Frontier module > comes with a mod_perl handler that, if not enturely suitable, is > easily modified to your needs. > > > I'm going to use modperl due to the embedded perl interpreter > > characteristics it provides, allowing initialization overhead to be > > incurred at startup. I also wish to use an in-memory, read-only hash > > structure shared across all modperl processes for access to the cached > > back end data, rather than making expensive calls to these stores for > > each request. Again, throughput is critical. > > Five hits/second should be absolutely no problem. If you expect slow > clients, a mod_proxy in front of things (http://perl.apache.org/guide) > can help. > > > I would like your thoughts on the cache management concept of the > > service. I'm looking at MLDBM::Sync as the mechanism for managing the > > filesystem representation of the in-memory hash content. What to manage > > the in-memory structure itself in terms of accessing its content? Is a > > Tie structure too expensive? I want to end up with a single structure > > accessible to all of the modperl processes, loaded at service > > Chip > > -- > Chip Turner [EMAIL PROTECTED] > Red Hat Network
