3) Being enabled by item 2, add more webservers and balancers
4) Create a separate database for cookie data (Apache::Session objects)
??? -- not sure if good idea --
I've never seen the need to do that. In fact, I would suggest you drop
sessions altogether if you can. If you need any per-session
information then put it in a cookie. If you need this information to
be tamper-proof then you can create a hash of the cookie's data that
you store as part of the cookie. If you can reduce the # of times that
each request needs to actually hit the database you'll have big wins.
Can I get you to explain this a little more? I don't see how this could
be used for truly secure sites because I don't quite understand how
storing a hash in a plain text cookie would be secure.
The thing I hate most about my "secure" applications is the fact that I
have to read the DB at the start of every request to ensure that the
session cookie is valid and to extract information about the user from
the session table using the session ID stored in the cookie. Hitting
the DB is the quickest way to kill performance and scalability in my
experience. I know a lot of true app servers (Websphere, etc..)
store this data in cached memory, but I was unaware that there might be
an option for doing this without using a DB with mod_perl .
