Re: Overwhelming a Web Application Server

[Pete Helgren <Pete@xxxxxxxxxx>]

At what point do you decide to purge the DB record? Do you had a batch 
job that periodically removes the records?  Seems to me that tens of 
thousands of records accumulating daily would lead to some space/size 
issues eventually, even if they are "nit" sized.  I am guessing there 
isn't much, even in transition, that you stored in relation to a 
session.  In my Java app there can be some fairly large objects that get 
attached to the session temporarily to save DB I/O.  Serializing them to 
the DB, even for a few seconds seems pretty expensive, might as well 
just do the DB I/O directly again, rather than serialize the object.

However, I jumped into the discussion mid stream so I may be well down a 
rabbit hole that is irrelevant.

Pete


Walden H. Leverich wrote:
> > But sessions are a different story - we've already established that
> >     
> they 
>   
> > often consume a lot of resources.
> >     
>
> Given that I would never store session state in memory, I disagree. I'll
> take the performance hit and store them in a DB when I use them. I want
> the stability the DB provides me. So, unused sessions that are just
> hanging out really don't cost anything more than a little disk space,
> and next to the audit-log tables, session tables are a nit. :-)
>
>   
> > I assume that database servers have limits to client connections
> >     
> (J2EE, PHP, 
>   
> > and .Net developers should know more about that than me - I'm an RPG
> >     
> programmer).
>
> Never tried to limit the number of connections, I assume it can be done.
> By the time you factor in key to wait time for the apps we're running we
> can satisfy something like 500 users per active DB connection (5000
> users w/10 connection, 50,000 w/100 connections, etc.) so there's little
> point in limiting the connections. But out avg DB request is well < 1ms,
> and page loads (some taking 100s of db requests) are running well < 1s.
>
> -Walden
>
>