Splitting up CFC

[Guest]

Hi,

We have an ecommerce application that uses a number of CF components.  Some of these are quite long with many functions.  Right now, each user to our site gets assigned a CFC object that is stored in his/her session.  So at the beginning of the session, there is a lot of CFC instantiations going on.  I am wondering whether this is the most efficient way in terms of speed and memory utilization.

Would it be better if I split up each CFC into two: one stored in the Application scope that contains all the functions, and another stored in individual's session scope that contains mostly the data.  So the session-scope CFC objects would access the application-scope CFC object for the functions.  Do you think this would improve the performance of the website?  What goes on behind the scene when a CFC object is being instantiated?

Thanks,

ML

[Adam Cameron.]

The footprint of a CFC instance in the session scope is quite a bit bigger than what one might think, and we have found that if one has session-based CFC instances on even a moderately busy site, the thing faceplants pretty quickly.

Our solution was similar to what you suggest: stick a CFC which has the methods but no state into the application scope, and just maintain a struct for the session data.  Structs are a lot smaller than CFC instances.

But you could try using a session-based object for the session data, and do some load testing to see what your RAM consumption is like.

--

Adam

[Guest]

Wow, they should really put that warning (against session-scope CFC) in all articles about CFC.  Most of what I read about CFC have been so pro-CFC that one would think that creating session-based CFC objects are best practice.

Thanks for the info.   I have a lot of work to do now.

[ilssac]

Too add to Adam's reply.

The instantiation of a component is one of the most expensive parts of the process.  If you can cleanly seperate your logic so that this happens less often, the would probably be a good thing.

[TLC-IT]

Think for a minute about the underlying implementation, which is Java.  Also visualize that the role of the server is to serve thousands of requests per second, among hundreds of active sessions, perhaps with dozens of simultaneously active server machines.

"A session" should simply be "a unique and valid session-ID token, which indexes into a host-side pool of data values."  ColdFusion gives you very easy access to that pool of values, as well as several (fast, and transparent) ways to implement the pool.

"A CFC, once instantiated," might incur a startup penalty but once it has been instantiated (as a Java object...) it becomes a shared resource that might be used for hours to come by many servers.  You do not want to pay that price repeatedly, either in terms of memory or time.

Since the session-data is, of course, a struct, which can be arbitrarily complex, you might design each CFC so that it stores "its" variables in a particular subkey of the session-data.  (And maybe you <cfset CFC_session_subkey = "whatever"> at the top of each CFC's source-code, just for consistency of coding.)  This will help to keep the data separated so that the various CFCs don't walk-on one another.