Actually, I disagree with Scott, somewhat... While the amount of data in the variables does increase the size of the data stored, it's the number of variables that greatly increases the complexity of your application. Programmers fight complexity. That's one of our jobs.
Now, the amount of data can usually be estimated, eyeballed, even, by cfdumping your session and seeing how much is there. 67 fields with an average of 100 characters, that's 67KB. The nearly more scientific way is to copy the cfdump out of the browser and paste it into notepad, save a file and check the file size. The actually more scientific way is to use a server debugger like CF8's server monitor or SeeFusion, etc. Let's say there's 10KB of data in your session. That's literally 10KB of RAM on the server. If you have 1,000 active sessions at one time, you'll be using 10MB of RAM. That's seriously nothing, not a problem unless you run CF on a 386 or a TI calculator. Many applications have far fewer concurrent users, and very few have significantly more. I had a site with 20,000 concurrent users and we were trying to save up to about 100kb per user, which is right up with the maximum memory allocation for a 32bit program (that's when we had to split it onto multiple servers). So like I said, memory size usually isn't the problem. Complexity is. If you're going to save each and every form submitted item into a session, make sure they're organized. session.firstName should not be next to session.prefersPepperoniPizza. session.user.firstName (a user struct, can even be <cfset session.user = form />) would be better and session.pizza.prefersPepperoni is tucked away in the pizza struct. Once you've refactored into structs, consider CFCs to hide any complexity you may be adding later on, such as database interaction. setUserData() now can just put it in so you can use getters later on in the app, but in a few months, setUserData() can save it to the database, no other changes to your app needed. Side note: if you're going to save each and every form submitted item into a session variable, I hope there is a ligitimate business case for this, otherwise, it may be smarter to put it in a database. If the users are anonymous, you can reference the users' data by their sessionID (like a client variable). For deciding what should and should not be in the session, it really comes down to your application and what rules apply. If you have a form that you don't want the user to have to fill out twice, make a judgement call based on how often the form will need to be populated and what the impact of hitting the database that often will be. If you find some data that you are going to be querying on ever request, just query it once and place it in the session. That's caching 101. nathan strutz [Blog and Family @ http://www.dopefly.com/] [AZCFUG Manager @ http://www.azcfug.org/] On Mon, Dec 8, 2008 at 9:23 AM, Scott Stewart <[EMAIL PROTECTED]>wrote: > I've inherited an application that uses session variables all over the > place.. I think every form variable has been moved to the session scope. > I'm in the process of documenting them, and I have 67 variables > documented so far. > > My question is: How much is too much and will having this many session > vars affect performance. > Secondly, when others on the list build apps, what criteria do you use > when determining when and where to use session vars? > > thanks > > sas > > -- > Scott Stewart > ColdFusion Developer > > Office of Research Information Systems > Research & Economic Development > University of North Carolina at Chapel Hill > > Phone:(919)843-2408 > Fax: (919)962-3600 > Email: [EMAIL PROTECTED] > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;207172674;29440083;f Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:316495 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
