Session Variables - how much is too much

Results 1 to 6 of 6

Thread: Session Variables - how much is too much

  1. #1
    besharah Guest

    Default Session Variables - how much is too much

    I&#039ll start by apologizing immediately for asking such a vague question, but here it is anyway: How many session variables can one carry before the load on the server is too great. I&#039ll simply say that I&#039ve come accross situations where I wanted to store say 7-8 string and integer values in session variables and was told that the application would, as a result, not scale well. How much is too much. Can you have a site with 400 concurrent users if each one uses 8 session variables each.<BR><BR>Thanks

  2. #2
    Jason Miller Guest

    Default RE: Session Variables - how much is too much

    Okay, here&#039s how session variables don&#039t scale well where "it" is server resources devoted to sessions:<BR><BR>Think of it as a rectangle: Each variable increases the height, each user increases the width. Now, if you have 400 users each carrying 5 integers, you&#039re keeping track of 2000 integers at any given time (within the session.timeOut span, default is 20 minutes). If your server can take that, great. But what if your site is unexpectedly successful, you need more variables, or your application gets moved to a smaller server?<BR><BR>When you know exactly what&#039s going on, session variables are fine. Chances are, however, that you don&#039t really know what&#039s going on -- it&#039s part of the job -- so session variables are too unpredictable (the "don&#039t scale well" part) for heavy use.<BR>

  3. #3
    Join Date
    Dec 1969

    Default RE: Session Variables - how much is too much

    The point of not using session variables is that they are in memory for the life of the session, which by default is 20 mins. So, even though a user has left your site, their session is still around in memory. At an extreme case, if you had a server with 20 MB of memory, and Session Variables totaling 1 MB, then you might only be able to support 20 users every 20 mins (i.e. the session life). <BR><BR>The other bad thing is that the session is only alive on one server. If you had a web farm, then you would have to send a person to the same server everytime (via a LocalDirector or other hardware/software solution) to insure that their session variables were available.<BR><BR>So, in short, the two things you should look at are:<BR><BR>1) Resource Usage - memory, database connections, etc being allocated for the full session life<BR><BR>2) Multiple Web Servers - as session state is only good on the server it originated from.<BR><BR>That&#039s where the scalability concern argument comes in. You should do look at your statistics regarding not just the number of concurrent users, but the number of unique visitors over the session time period. If every couple of seconds, a new set of 400 users come in, then your resource usage is going to skyrocket.... <BR><BR>In my experience, I&#039ve seen sites with ~700 simultaneous users storing about 30 session variables and objects per user....on servers having 1GB+ of memory.<BR><BR>James

  4. #4
    SALA Guest

    Default RE: Session Variables - how much is too much

    IT IS BETTER TO AVOID SESSION VARIABLE. Try to do it with hidden fields.<BR><BR>Cheers!!!!!!!!

  5. #5
    Join Date
    Dec 1969

    Default RE: Session Variables - how much is too much

    For the most part I agree. I&#039m NOT currently using any session variables, but it DOES GET MESSY w/o them. Passing values from page to page w/submits or in the query string (avoid, if at all possible) is a pain. There are a few limitations in the "way" you present your data that can get tricky.<BR><BR>As mentioned (I belive) you can use &#039STICKY SESSIONS&#039 across a web farm. Once again you do have to keep in mind the amount of hits! If its an intranet w/a limited amount of users you can develop more quickly using session vars (even reduce the time if u want).<BR><BR>HTH<BR>Steve

  6. #6
    John Booty Guest

    Default RE: Session Variables - how much is too much

    One way to get around over-reliance on Session variables without having to pass around 200 difference Querystring variables from page to page is to pass a few key values from page to page. <BR><BR>For example, in an online shopping site, you might want to pass only the user&#039s ShopperID from page to page. The shopping cart contents could be stored in the database, rather than sessions or querystrings or whatever.<BR><BR>This also makes your code much cleaner. Rather that passing around 100 ugly session and hidden variables, most of these things are stored in the database where it&#039s nice and clean. Also, if you&#039re passing too much info around in the querystring or hidden fields, you can wind up being screwed if the user opens multiple browser windows. Trust me. :)<BR><BR>Two potential caveats to this approach:<BR>1. This method will make you rely more on your database performance, since all your info is living in the DB. Make sure you&#039re using a fast database like SQL (NOT Access) and that you&#039re doing proper cleanup with your database objects (set them equal to Nothing when you&#039re finished). Replace complicated SELECT statements with stored procedures whenever possible. Make sure you&#039re using the right locktype and cursor type. And for god&#039s sake, don&#039t use crappy ADO filter commands to manipulate your data, do it all in SQL.<BR><BR>2. By only passing a UserID or ShopperID in the querystring, you could have a security hole. For example, if I see a URL like this:<BR><BR><BR><BR>... I know I can change that 1234 to a 1233 and probably edit someone else&#039s info. :) The solution is to keep the UserID in a Session object, or to pass multiple pieces of info in the querystring like:<BR><BR> ke&LastName=Smith&ZipCode=99999<BR><BR>That makes it harder for a user to get into places he shouldn&#039t by hacking the URL. :) <BR><BR>In summary:<BR><BR> PASS AROUND ONLY A LITTLE "KEY" DATA IN SESSION/QUERYSTRING/HIDDEN FIELDS... STORE THE REST IN THE DB WHERE IT BELONGS!!!!!<BR><BR>Hope this helps... :)<BR><BR>-Booty<BR><BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts