We clean up sessions that haven't been touched in 24 hours at 6AM each
morning, it's an automatic job in the DB. You're correct, we don't store
much in session, we use it to tell us about the, um, session (user,
role, login date, connection-string (multi-db) etc.) but we don't store
data elements in session. This is for two reasons, first, we'd rather go
back to the DB for the data, since session will be stored in the db
anyway*, and second, storing info about the state of your application in
session gets wonky when the user open up a second tab (or 3, 4, 10th) to
your application. What's the "current" order when there are 5 tabs open
on the user's screen each looking at a different order. We got screwed
by that early on and have pushed to avoid it ever since.
We will use in-memory caching to avoid DB ios for some common queries.
For example, we show a list of "messages" and "links" in our common
left-hand nav section. Since these change very infrequently we cache the
result in memory and refresh ever 5 minutes. Means it can take up to 5
minutes to see the effect of adding a message, but we avoid 1000s of
lookups to reload the same data.
-Walden
*Session IO is still faster than DB io since session isn't Full logged,
and the "data" databases are, but that's generally a nit.
As an Amazon Associate we earn from qualifying purchases.
This thread ...
Re: Overwhelming a Web Application Server, (continued)
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.