On a high volume site you might get better performance from session rather than client
variables, but on most CF
sites the important things are how fast it can be coded and if the site is stable. A
lot of people's code I have
seen does not lock session variables correctly. And this is the cause of much CF
instability and server crashes. So
on this point alone I would recommend the average CFer to use client variables over
session. For me a best practice
is what the average coder can do correctly 100% of the time, rather than what is the
fastest possible code every
time. :-)
For an example of session locking craziness - some folks try to copy the session scope
inside CFLOCKs then use the
copy without locks. Unfortunately if you use StructCopy to do this any structures in
your session scope will only
have the pointers copied and when you access the copy it will really access the
session var itself! However the
copy will fool the CF admin's strict lock checking for CFLOCK making you think your
site is lock safe when really
it isn't... (The 4.5.1 duplicate() function was created to get around this issue).
The performance with client variables in SQL server is fine for most sites. You can
improve things by adding
clustered indexes for the client storage tables. CDATA has one index on CFID and APP
(called "id1"), cluster it;
for CGLOBAL, cluster index "id2" which is on CFID. You can also improve it by using a
dedicated SQL server with
lots of RAM for just the client vars database if you have a clustered high volume site.
Has any one else done a volume test on locked session vs client vars?
- Michael Smith, TeraTech, Inc http://www.teratech.com/
Bob Silverberg wrote:
> Hooray, another interesting thread on CF best practices!
>
> I've spent a lot of time agonizing over the client vs. session variables
> debate (well, not really agonizing, more like thinking about it while I'm in
> the shower), and here are my thoughts.
>
> Unless I need the variables to persist from session to session, or I need to
> implement in a clustered environment, I always use session variables. Why,
> you ask?
>
> This is based on one of my prime objectives, which is to minimize calls to
> the database. Why continually read the same value from a database, when you
> can store it in RAM which is much, much faster? I believe that you should
> only go to the database for data that you either don't already have, or that
> is stale. You'll hear many people extol the virtues of query caching, but
> I'll bet that many of those same people use client variables extensively.
>
> I didn't realize until recently the sheer amount of database activity that
> client variables generate. Did you know that if you have client variables
> turned on CF will generate two select statements for every single page hit?
> And, if you don't turn off global client variable updates (which are turned
> on by default), you also generate an INSERT/UPDATE statement for every page,
> even if you aren't accessing any client variables on that page. To me
> that's a whole lot of unnecessary database calls.
>
> The one big argument in favour of client variables, IMHO, is that you cannot
> use session variables in a clustered environment. So, if you think that you
> might have to run in a clustered environment in the future, you'll probably
> save yourself a lot of time by using client variables from the get-go. I
> think that the "no locking required" argument should be questioned - not
> dismissed, but questioned. If the argument is based on the desire to avoid
> writing a few (or even many) extra lines of code, I think it is
> questionable. Writing code is what we do, and if the best solution requires
> 10% more code, well, so be it. If the argument is based on performance, I'd
> be very surprised if the cost of the locks exceeds the cost of all of those
> database calls.
>
> I'd be interested in hearing from anyone who has any performance measures of
> locking vs. client variable db access, as well as other arguments
> for/against session/client variables.
>
> Bob
>
> -----Original Message-----
> From: Michael Smith [mailto:[EMAIL PROTECTED]]
> Sent: April 10, 2001 2:53 PM
> To: CF-Community
> Subject: Re: session.session_id
>
> Kristin
> Wow! Thanks for replying to this question in such detail. I didn't know so
> many famous CF authors were on this
> list! :-)
>
> I know the default timeout for client vars is usually set to be 10 days or
> something long but as I understand it
> they do exactly the same as session varialbes in maintain info across page
> requests for one user. For me the "no
> locking required" benefit outweights the having to set up a database to
> store them in (which the CF Admin does for
> you when you create a client var datasource).
>
> To deal with the long time out I usually store the date/time of the last
> page access in a client var and if the
> difference between it and current time gets greater than the timeout I want
> then I CFLOCATION the page to the login
> screen.
>
> - Michael Smith, TeraTech, Inc http://www.teratech.com/
>
> Kristin Aileen Motlagh wrote:
>
> > [snip]
>
> > Also, to Michael Smith's comment:
>
> >
> > "If you don't have any structures or queries in the
> > session vars it would be
> > best to convert to client vars (stored
> > in database rather than registry) as these don't need
> > locks at all..."
> >
> > Sessions and client management have two different
> > purposes. Session management is meant for a short
> > period of time, and does not need data source setup.
> > Client variables are meant to persist over multiple
> > sessions. It is funny because when session variables
> > first came out...everyone was saying...stop using
> > client variables!! But I think you need to judge based
> > upon your purpose and application what is best. Do you
> > use them interchangeably?
> >
> > -Kristin
> >
> >
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/cf-community@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
