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
Mason-users@lists.sourceforge.net
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
Mason-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mason-users
