To Mitchell or other Pro-->

Results 1 to 7 of 7

Thread: To Mitchell or other Pro-->

  1. #1
    Ian Stallings Guest

    Default To Mitchell or other Pro-->

    *<BR>I&#039m working on a website that stores user preferences <BR>in the session object in an array. It&#039s a 2 dimensional <BR>array, but in that array are multi dimensional arrays <BR>which store information on specific devices that the user <BR>has.<BR><BR>Then when the time comes to use this data, the ASP developer<BR>has to loop through these arrays to get the values.<BR>They do this under the rational that it will save DB calls<BR>to the DB. I have no disagreement with that but I think this <BR>is wasting a large amount of memory that could be saved.<BR>I will test eventually when I get the chance but I thought<BR>I&#039d ask around first.<BR><BR>I wanted to know:<BR><BR>what do you think of this technique?<BR><BR>what is the memory requirement for each variable stored in<BR>a session object? I am assuming it&#039s the same as a variant<BR>but is there any other memory use on top of this?<BR><BR>How computationally expensive are DB calls from a COM object<BR>using ADO compared to using the session object to store <BR>preferences?<BR><BR>thanks,<BR>Ian S

  2. #2
    Join Date
    Dec 1969

    Default RE: To Mitchell or other Pro-->

    My skin crawls when I hear people discussing Session variables. Session variables, in my opinion, are pure evil. (See<BR><BR>Some of the problems with using Session variables include: the client must accept cookies for this approach to work; Session varaibles are persistent little buggers - if your Session.Timeout property is set to 20 minutes, and 100 new people visit your site every 10 minutes, you will have, after 10 minutes, 200 instances of session variables floating around, with only 100 of them being used.<BR><BR>A great article to read on why NOT to use Session variables can be found at:<BR><BR><BR>Go with the database approach. Connect as late as possible; close the connection as soon as possible. Make quick, efficient hits, get the information, close the database connection, use the information, and your done. I think you&#039ll find the performance to be acceptable.<BR><BR>Good luck with your project, and happy programming!

  3. #3
    Rokea Guest

    Default RE: To Mitchell or other Pro-->

    I think that storing arays as big as those seem to be is asking for trouble. I am using sessions variables (to store only short strings) and the users noticed a big slow down when they were a lot using the server (i dont know how much they were, 50-100). <BR><BR>As you might say, the problem is that the session times out only 20minuts (default) after its use, so this uses up a lot of memory an can definitively jam a sevrer, depending on the number of simultaneous users on the site and what is the exact size of those arrays. <BR><BR>I can only say that using session variables with more than just a little string in it on a server that possibly has a lot of simultaneous users WILL result in a slow down, except if you have a very good way of releasing those objects once their work done (like session.abandon or =""), which is, i found out, tough to track!.<BR><BR>However, i would be interested, like you, in having exact details and or solutions concerning this matter..<BR><BR>Rokea

  4. #4
    Rokea Guest

    Default RE: To Mitchell or other Pro-->

    I think that what Scott just said is actually wuite right!, but as i said, if you can track sessions and that you dont have a lot of data in it, its better than a database connection, well, in my opinion.<BR><BR>there could be a good alternative to this. If your in SLQ Server, you could use the way Scott mentionned paired with the connection spooling technique. This method keeps opened connetions in a spool, later reusable, so that you dont loose precious server processing time on constantly closing-reopening connections.<BR><BR>Rokea<BR><BR>

  5. #5
    Ian Stallings Guest

    Default Thanks Guys!

    Thanks you guys for confiming my ideas on session<BR>variables. I came into the project after the design had already<BR>been approved and implemented so Im sure I will have<BR>a hard time raising this isssue without becoming a major pain<BR>in the #!&@$. But If I do get hard data on why it&#039s the wrong<BR>implementation I will definetly post the info on 4guys.<BR>Unfortunately it comes down to - how will a change in code<BR>benefit the company? and Is it cost effective?<BR><BR>I think we can avoid issues like these if we keep educating<BR>ASP developers on the potential pitfalls of ASP.<BR><BR><BR>thanks again!<BR><BR>Ian S<BR>

  6. #6
    Rokea Guest

    Default RE: Thanks Guys!

    a few weeks ago, i entered a project (, something similar as what you described (except the sessions arnt that HEAVILY used heheh), thats how i learned about session variables, i just read, and read :) like you, i coulndt change a lot of things since the project was too close its ending. The best i could do was learn for the next time, tell other programmers about it, suggest changes we could do.. <BR><BR>As for the benefit of the company and the cost efectiveness.. since the project is too advanced, i would let go this way, because anyway its not your responsability. If they are satisfied with the result, its ok... but if the server keeps on jamming and giving errors due to memory or things like that... well then you could propose to make some changes...<BR><BR>good luck!<BR><BR>Rokea

  7. #7
    Ian S Guest

    Default RE: Thanks Guys!

    It is my responsibility now. Im one of the lead <BR>developers of the site. It is a large web site<BR>expecting large amount of return users (I&#039d say<BR>100,000 or so). Typically this wouldn&#039t be much of <BR>a hassle for a average content based website, but this <BR>website is a service based, very back end intensive <BR>site.<BR><BR>But the problem is that is was developed too aggresively<BR>and the design suffered because of that. This is pretty <BR>typical considering the rush to make dollars on the Internet.<BR><BR>A few weeks ago I was here on the weekend tracking down<BR>a related bug that was crashing the web servers at 30 users!<BR>Not too bad considering they were concurrent, but these are<BR>1 gB ram, quad xeon etc etc beast machines! I will have to<BR>test the 2 different methods, then look at all the data<BR>from the tests and describe to the higher ups why it will<BR>be in their best interest to redesign the site and potentially<BR>stop development (read: revenue) until a new design can be<BR>determined. I got to have hard data before I even contemplate<BR>talking to them about it but it should all fall into place.<BR>At the very least it will have a bubbling effect and the next<BR>web site design will not use session variables.<BR><BR><BR>thanks for all the input!,<BR>Ian Stallings

Posting Permissions

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