Subject: Re: Session variables & RAM vs. DB Queries From: Vic C <[EMAIL PROTECTED]> === Poolman can do caching for you. You should keep session memory to a minimum. More memory on DB server would also cache the querries. hth, V.
Adam Hardy wrote: > Hi Richard, > I've never done calculations on how much RAM my session variables take > up. I did once ask around about sessions, I thought there might be > hidden overheads to session memory or something, but apparently not. > Theoretically with lots of RAM your server should cope with a fair > amount of stuff in a fair number of sessions. It just requires you to > sit down with a load tester to fire http requests at your prototype and > some sort memory monitor on your server. > > Adam > > Richard Diaz wrote: > >> Well when scaling isn't RAM is cheap? and RAM is >> faster that running queries right? I'd rather store >> things in session then start querying more when more >> users connect..."I have the need, the need for speed." >> >> I have people writing to the database and others >> reading from it. >> >> I need to find a balance and adjust the queries to >> session variables for optimum performance, static at >> first, make it dynamic later. >> >> Alot of the user session variables do not have to be >> sync'ed with the database... their data is always more >> correct than the database and the records and only >> editable from the user and no one else. >> >> Finally I do have some application variables that all >> users will share and this data will change only once a >> day. >> >> Rich >> >> >> --- Adam Hardy <adam. >> [EMAIL PROTECTED]> wrote: >> >> >>> As long as you've got connection pooling and a >>> decent piece of hardware, you should be able to carry out all the >>> non-trivial >>> database queries you require, given an average application requirement. >>> >>> The amount of user information you hold in their >>> session is limited to the amount of available memory you have, >>> divided by >>> the expected absolute maximum number of concurrent sessions you >>> predict. >>> >>> I am curious though due to the way you phrase you >>> question, are you contemplating balancing the session memory usage >>> against database usage dynamically? >>> >>> And another question, how much user info can you >>> have in your application that is static enough to hold in their >>> session? >>> >>> Regards >>> Adam >>> >>> Richard Diaz wrote: >>> >>> >>> >>>> I'm currently doing DB Queries and holding the >>>> >>> >>> users >>> >>> >>>> information in session objects... trying to keep >>>> >>> >>> the >>> >>> >>>> query load on the database down to a minimum by >>>> >>> >>> using >>> >>> >>>> these session objects (MVC2). >>>> >>>> My question is where do I draw the line as far as >>>> >>> >>> how >>> >>> >>>> much RAM each user gets? When do I free up those >>>> session objects and querying the database for >>>> information again? >>>> >>>> Are there any guides on this? >>>> >>>> thanks in advance, >>>> Rich >>>> >>>> >>>> >>>> __________________________________________________ >>>> Do You Yahoo!? >>>> LAUNCH - Your Yahoo! Music Experience >>>> http://launch.yahoo.com >>>> >>>> -- >>>> To unsubscribe, e-mail: >>> >>> <mailto:[EMAIL PROTECTED]> >>> >>> >>>> For additional commands, e-mail: >>>> >>> >>> <mailto:[EMAIL PROTECTED]> >>> >>> >>>> >>>> >>>> >>> >>> >>> -- >>> To unsubscribe, e-mail: >>> <mailto:[EMAIL PROTECTED]> >>> For additional commands, e-mail: >>> <mailto:[EMAIL PROTECTED]> >>> >>> >> >> >> __________________________________________________ >> Do You Yahoo!? >> LAUNCH - Your Yahoo! Music Experience >> http://launch.yahoo.com >> >> -- >> To unsubscribe, e-mail: >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> >> >> >> >> > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
