Hi Lisa, Instead of generating the data and retrieving it on each request, how about caching the output of the components? You might want to look at HTML::Mason::Request's cache_self().
Alfie -- http://www.Share-House.com.au FREE Share House Advertising On 8/7/07, Mark Torrance <[EMAIL PROTECTED]> wrote: > I'm not the best expert on this, but seeing as how I appear to be awake at > this hour, I'll try to give an answer. > > I think your hunch is also a really good choice. By predefining this as a > global in the handler.pl, it should be loaded into mod_perl "before" each > Apache process is forked off. That means the same RAM will be used to > provide this data to each separate mod_perl instance, unless + until you > modify the values in that hash from one of the Perl instances -- at that > time, it would be "copy on write" which would make a separate copy of the > whole data structure in that particular Apache instance (pid). > > But since you don't plan to change these values ever, you should be fine > with the approach you contemplate. > > Here's another alternative you might consider: If you are looking for a way > to have the lookup be fast (faster than you could get from a database) but > you don't want to let each Apache process grow as large as this data > structure, you could store it in Memcached. Have a look at > Cache::Memcached, which you can call from Mason or any other Perl program. > All your separate mod_perl instances can talk to the same Memcached > instance, and you can run it on the same machine or a separate machine. It > works like a large hashtable, where you can store any Perl data structure in > it and associate that with a key. It's probably overkill for this case, but > if you find your mod_perl runtime size is larger than you would like, you > could consider it. It does require you to run a separate "memcached" daemon > process which will store all this content -- think of it as a simple > RAM-based database with a simple hashtable-like API to get data in + out. > It's most useful when you want to be able to write and read from the data > structure, from many client processes, and you want to be guaranteed that > they will all see the "same version" of the content. > > --Mark Torrance > > > On Aug 7, 2007, at 12:01 AM, Lisa Klein wrote: > > Hi All, > > I'm developing a Mason web application that needs to perform a large amount > of variable substitution. (e.g. 'hello' -> 'bonjour', 'bye' -> 'au revoir', > etc...) There are about 3,000 key/value pairs associated like this. About > 25% of all components perform a good amount (50+) of these types of > substitutions, so the replacements need to happen quickly. > > Since it seems unwise to use a database to perform so many operations so > frequently, I'm leaning towards using a predefined hash. e.g.: > my %translate = ('hello' => 'bonjour', 'bye' => 'au revoir', ..... 3,000 > more key/value pairs ...); > $var = $translate{$var}; > > What would be the advisable method of defining such a hash in a Mason > environment? Currently I'm considering: > > 1. loading a global %translate in handler.pl, making it available to all > components > 2. defining %translate in the <%once> section of components that perform > substitution > 3. storing %translate in a mason cache, and retrieving it in components that > perform substitution > > The global hash defined in the handler.pl would make my life easiest, but > I'm concerned that I don't fully understand the implications (if any) of > defining such a large global data structure in this way. > > I'm definitely open to any other suggestions as well. Thanks in advance! > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> > http://get.splunk.com/_______________________________________________ > Mason-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mason-users > > > ----------------------------------------------------------------------------------------------- > Mark Torrance, CEO, Vinq, LLC www.vinq.com [EMAIL PROTECTED] > 408 236-7701 (w) 408 420-9239 (cell) 408 516-9479 (fax)560 S. Winchester > Blvd., Suite 500, San Jose, CA 95128 > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Mason-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mason-users > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Mason-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mason-users
