I haven't been following the thread, but thought I'd chime in. You're exactly right, Nando. Caching CFC instances in persistance scopes (application or server) usually results in a huge performance increase. Instantiation of CFCs is fairly expensive, because of their dynamic nature, so if you can pay that cost only once, you'll be much better off.
The one thing to watch out for is that since the CFC is in a shared scope, it's instance data is also in a shared scope, and therefore needs to be locked appropriately. There is a debate as to whether that's better performed within the CFC (simplifying the calling code), or outside (which makes the CFC more encapsulated, because it doesn't know or case where it was instantiated to). I prefer the former, because I always end up forgetting a CFLOCK somewhere, but if I only have to remember it when I'm building the CFC, I tend to do better. Along the same lines, its VERY important to properly use the 'var' keyword in your CFCs. If you don't, those variables become instance variables of the CFC, and need to be locked. There were numerous problems of this nature in the Mach-II framework code that Sean worked out as they started load testing at MM and started having weird bugs because of it. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Nando > Sent: Tuesday, December 02, 2003 5:10 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Basic CFC Design Question > > Brandon, > > I'm fairly new to cfc's myself, and maybe someone else can > answer this with greater > precision, but there seems to be not much of a performance > hit associated with > invoking a CFC from within another. The big payoff comes, *i > think* - this is just my > impression because i don't have the time to get very deep > into this - when you cache > an instance of the cfc you need to invoke in a persistant > scope, remembering that the > instance data would also be cached. I don't understand all > the details of your > situation, but my naive hit on it is you could create a > datasource object, cache that > in application scope, and only reinitialize it, refreshing > the instance data, when > your application updates or adds datasources. Remember also > that the instance data > stored in the cached object could be calculated or derived > from many sources. (Like my > breadcrumb instance data for a website is derived from all > the pages in the site.) > > I think that would be much better than those includes ... > someone correct me if i'm > wrong! > > A good example to look at the performance question might be > the MachII framework. I've > read that on a production server, it takes about 20 ms for > the framework itself to > process a request. There are a substantial number of cfc's in > the framework, and much > | all of it is loaded into the app scope. Composition seems > to work very efficently. > > OH! and remember not to trust you debug output timings when > looking at cfc > performance. Most of the reported execution time, 4 or 5 > times more than actual in the > case of the machii framework, is from the debugging template. > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Brandon Harper > Sent: Tuesday, December 02, 2003 11:46 PM > To: [EMAIL PROTECTED] > Subject: [CFCDev] Basic CFC Design Question > > > Hey all, > > I'm new to the list, and haven't yet had anytime to lurk to > see what this > list is all about, and I apologize if I'm asking a question > which has been > answered before (I don't see a link to any archives on the > CFCZone site), > or if I'm asking a question that doesn't belong here. > > For a little background about myself, my name is Brandon Harper, and I > live in Denver, Colorado. I've been developing in ColdFusion > right around > the time 3.0 was released (a bit over 5 years now), I'm a Junior as > Computer Science major, and have been on computers since age > 3 (I recently > turned 25), and have been programming since age 8 or so. My > niche areas > of expertise beyond ColdFusion are in FreeBSD, Data Warehousing, and > general topics such as application security, and I'm starting to get a > pretty good knowledge of advanced analytics/scoring. > > Anyhow, I'm in the process of creating a "Data Services > Layer" in CFC's > which all of our applications at work will eventually use. > We have around > 180 different datasources of various LARGE datasources, of which the > structure of those sources changes on a regular basis. They > also have to > have various security, logging, and availability parameters > checked and > defined during each query for compliance reasons. These sources are > exposed to our various web products, as well as some XML > Gateways which > will probably be upgraded to SOAP once this project is > completed-- but the > DS Layer would sort of be the universal location that all of > our products > would go to for access to our data instead of every application being > essentially a one-off as far as logging, security, and access to these > sources is concerned. > > If I were working in Java (which I'm admittedly quite green in at this > point), I'd probably setup a hierarchy similar to this and just use > "implements" to roll-up the various classes: > > +--Dataservices.class (Main Interface) > +----DataManager.class (provides logging, security, checks DSN > availability, then runs the individual query) > +-----Datasource1.class > +-- doDatasource1Query() > +-- getDatasource1RecordCount() > -----Datasource2.class > -----Datasource3.class > > .. or something like that at least. > > I'm still setting up the structure of the application, and I > keep chasing > my own tail with design issues since there isn't a feature similar to > Java's multiple inheritance (with interfaces) to tie CFC's to each > other. In other words, I have fundamental issues with not > being able to > extend/inherit other CFC's which are all on the same level > (such as all of > what would be each CFC for each different datasources).. using extends > only works with CFC's that are in different levels in a hierarchy. > > Sorry to ramble.. on with the questions... > > 1.) I noticed that on Sean Corfields article "Software Design > Patterns for > Flash Remoting" ( > http://www.macromedia.com/devnet/mx/flashremoting/articles/fac > ades.html ), > the facade is setup to just invoke the other components via > cfinvoke. The > skeptic in me assumes that this would be a pretty big > performance penalty > in a busy environment, esp. when passing big sets of data between the > components since you are instantiating the CFC each time you > call it? I > haven't actually worked with an application which didn't instantiate > objects into a shared scope, so I wouldn't have an idea offhand how > harmful it is. > > 2.) About the only other way I can think of offhand to do a similar > feature to doing multiple inheritance in CFC's without having > to cfinvoke > each time would be to create a CFC full of cfincludes which > included all > of the various files which made up the individual datasources (and > associated functions). Such as: > > datasources.cfc > - datasource1.cfm > - datasource2.cfm > > That seems like a big, messy hack to me though. Perhaps the cfinvoke > method is more painless than I think? Any other suggestions by > chance? Hopefully I'm explaining myself reasonably well? > > The main reason I'm trying to keep each datasource seperate > is so that a > developer can check out a single file for each datasource if > it needs to > be modified rather than checking out a CFC which contains all of them > which more than one person might need to use at the same time. > > Thanks, > > - Brandon > > -------------------------- > http://booms.net > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
