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:46 AM, Ian Skinner <[EMAIL PROTECTED]> wrote: > Scott Stewart wrote: > > My question is: How much is too much and will having this many session > > vars affect performance. > > > > It is more if the amount of data in the variables then the number of > variables. One session variable containing a 5k structure will have > more of a performance impact the 67 variables containing booleans. But > yes session variables can have a performance impact. > > > Secondly, when others on the list build apps, what criteria do you use > > when determining when and where to use session vars? > > I use session liberally because they are simple and handy. But I work > on low load corporate intranet applications almost exclusively. If you > are developing the next 'My Space', even a small amount of data repeated > millions of times will have an appreciable impact and will need to be > accounted for. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:316490 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4