Adam D. wrote:
well i was kind of asking how long a session should remain in the DB.
so update_at < ? should be how many days ?
That depends on your application. What makes sense for your app? If you
have a news site, it probably makes sense for the session to expire in a
couple of days. If you have a store, you might want the contents of
someone’s shopping cart to reappear even if they haven’t visited for a
couple of months.
It’s worth thinking a little about the dynamics of the session
population which vary among different types of sites.
If you are planning for 1 million visits per day, how many of those are
new visitors? Are you using cookies, or logins, to reattach users to
their sessions? That means that you aren’t going to be adding 1 million
new rows to the session table, only some fraction that depends on the
number of new users.
If 90% of your visitors are returning in the interval before your
sessions expire, that means that your db is only growing by 100,000 new
sessions per day.
On the other hand, if 90% of your visitors are new, then your sessions
table is growing by 900,000 per day.
If 90% of your visitors are new, then there probably isn’t much value in
the state of you application, so you can expire sessions more quickly,
but if 90% of your visitors are returning, there is probably some value
in holding onto the state longer.
Also I do need sessions, I didnt think i needed an entry in the DB for
one if a session never got populated. Seems like overkill to me
especially for a website that gets tons of traffic.
If you store your sessions in the db, then you need a entry in the db.
You have already made that decision unless you are willing to undertake
the effort of developing a two-tier session store. You could mark some
sessions as keepers based on rules that only you know, but unless you
have evidence that this is really a problem, I wouldn’t bother.