md wrote:
>We are using a load-balanced
>system; I shoudl have mentioned that earlier. Won't
>that be an issue with caching to disk? Is it possible
>to cache to the db?
>
There are a few ways to deal with this. The simplest is to use the
"sticky" load-balancing feature that many load-balancers have. Failing
that, you can store to a network file system like NFS or CIFS, or use a
database. (There are also fancier options with things like Spread, but
that's getting a little ahead of the game.) You can use MySQL for
caching, and it will probably have similar performance to a networked
file system. Unfortunately, the Apache::Session code isn't all that
easy to use for this, since it assumes you want to generate IDs for the
objects you store rather than passing them in. You could adapt the code
from it to suit your needs though. The important thing is to leave out
all of the mutually exclusive locking it implements, since a cache is
all about "get the latest as quick as you can" and lost updates are not
a problem ("last save wins" is good enough for a cache).
>The "modules" will consist of a "pages" module with
>the names of all the pages the user has created (with
>links) and a "emails" module which will display all
>the features that the user is getting via email.
>These modules will be displayed on every page.
>
>You can see that almost everything is user-specific.
>
The relationships to the features and pages differ by user, but there
might be general information about the features themselves that is
stored in the database and is not user-specific. That could be cached
separately, to save some trips to the db for each user.
>Right now I'm storing the page names/ids in a hash ref
>in the session (the emails module isn't live yet), but
>I thought that I would change that and only store the
>module id and pull the names from the db (if the user
>hasn't turned off the module) with each page call.
>
You can cache the names too if you want to, but keeping them out of the
session means that you won't be slowed down by fetching that extra data
and de-serializing it with Storable unless the page you're on actually
needs it. It's also good to separate things that have to be reliable
(like the ID of the current user, since without that you have to send
them back to log in again) from things that don't need to be (you could
always fetch the list of pages from the db if your cache went down).
- Perrin
