--- Perrin Harkins <[EMAIL PROTECTED]> wrote:
> 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).
I haven't looked at the cache modules docs yet...would
it be possible to build cache on the separate
load-balanced machines as we go along...as we do with
template caching? By that I mean if an item has cached
on machine one then further requests on machine one
will come from cache where if on machine two the same
item hasn't cached, it will be pulled from the db the
first time and then cached?
If this isn't possible, I'm not sure if I'll be able
to implement any caching or not (some of the site
configuration is out of my hands) and everything seems
so user specific...I'll definitely reread your posts
and go through my app for things that should be
cached.
I would be curious though that if my choice is simply
that the data is stored in the session or comes from
the database with each request, would it still be best
to essentially only store the session id in the
session and pull everything else from the db? It still
seems that something trivial like a greeting name (a
preference) could go in the session.
> 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.
The only thing I can think of right now is a
calendar...that should probably be cached. The only
gotcha would be that the calendar would need to update
every day, at least on the current month's pages. But
this is only on a "feature" page, not a users created
page (that is a user can click a link on their daily
page that takes them to a feature page where they can
go through archives).
> 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.
Even though there are some "preset" pages, the user
can change the names and the user can also create a
cutom page with its own name. So there could be
thousands of unique page names, many (most) specific
to unique users (like "Jim's Sports Page", etc.). Not
to mention that between the fact that the users' daily
pages can have any number of user selected features
per page and features themselves can have archive
depths of anywhere from 3 to 20 years, there's a lot
of info.
> 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).
Very good advice. I've found that occasionally
something happens to my session where the sesssion id
is ok but some of the other data disapears (like
current page id) which really screws things up until
you log out and log back in again. This leads me to
suspect that I've answered my own question from above.
It's just whether I can cache or not.
Thanks for all your time and help.
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
