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

Reply via email to