I assume that the variables will be changing while the server is running, as opposed to being set once when the server starts and you'll only change them when you shut down the server. (The latter is trivial).
Probably the best solution is to use either a database to store the variables, using SQL to retrive the values of the variables, or to use something like a tied hash pointed to a file to get the variables when requested. The latter, however, might suffer from file-locking-like problems, though you might be able to wrap a "while ( cant-open-file ) { }" loop in your tie such that you can get to the file when it's available.
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
| [reply] |
First, check what the performance hit is to read the config info from the db everytime you need it. If you have a low-volume sight, or you are hitting the db to serve the page anyway, you may not notice the overhead.
Another solution is to keep the timestamp in your config hash and then decide to refresh from the db every "n" minutes regardless. Then the performance his occurs on a small fraction of the requests.
You could (through stored procedures or your maint page), write the config info to the file system. Then either every request, or comparing timestamps on the file and the hash, refresh as needed.
Or set the apache children to die after "n" requests and when they initalize they can get the current config, etc. | [reply] |
| [reply] |
Depending on the variable, I would be suspicious of whether
IPC::Shareable is a net win.
Sure, the database is a point of contention in the site.
However shared memory that you access frequently can quickly
become a bigger one. And any design based on using shared
memory cannot be scaled by running on multiple machines.
Given the scalability implications of that statement, I
would work to avoid shared memory without first doing a
detailed evaluation of why I thought it fit my problem.
And if I was going to use it anyways I would be inclined
to hide it in a function call in a module that would
memoize it upon first access in an interpreter. In other
words I would work to make it as small a point of
contention as possible.
FWIW I met Rusty (of Kuro5hin) last summer, and when he
mentioned he was using IPC::Shareable in the released site
this was my gut reaction. And indeed when his site was
re-released and hit load, guess what component caused it
to fall over?
| [reply] |