Quick note on speeding up the performance of CFCs... On a 2GHz P4 the creation of a component with CreateObject() takes (upto) 15ms. If you're using a _lot_ of objects - i.e. you're representing your system in a highly OO way - then your page times start to get reallllly huge.
At this point you have, I think, three options - 1) Write 'em in Java. CF apparently creates Java objects with CreateObject in nigh-on 0ms. 2) Manually cache an instance of each object in the Application scope. Implement your own function - say CreateComponent() - that will get a copy of the component out of the App scope. Of course a problem with item 2 is that if you change your component then the cached copy would be out of date. I'm currently looking into a way of getting around this by using the individual IDs assigned to a class' functions. 3) If you have to make a number of instances of an object during a request, then you can implement item (2) for each request therefore eliminating the problem in item (2). -- Oliver Tupman Key Systems Geotechnical Rich Z wrote: > Thanks for the insight. Very helpful. > > > -----Original Message----- > From: Sean A Corfield [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 24, 2003 3:46 PM > To: CF-Talk > Subject: Re: CFC's and how they work. > > On Thursday, Jul 24, 2003, at 10:07 US/Pacific, Rich Z wrote: > >>I've got a box here at work and it has CFC that is going to get pretty >>hard. I'm a bit wary of scalability, which leads me to a few > > questions: > > macromedia.com is very CFC-heavy and supports over 15,000 concurrent > active sessions during peak morning load so, yes, it can scale. > > >>1. What does CFMX do about caching CFC's? Does it cache them? Does >>it cache them along with parameters? > > > Each CFC and each method within a CFC is converted to a Java class > file, just like each CFM file, and that compiled class file is loaded > (and cached in memory). > > As Ray said, the lifetime of each CFC instance is whatever you tell it > to be, i.e., depending on how you use and store it. > > >>2. Let's assume a CFC method requires 3 seconds for output in >>testing. Once in production, let's assume that load is significant >>enough such that the CFC will be invoked every second. Will the >>invocation have to wait for the CFC to finish processing the previous >>one? I guess another question I'm asking is - do CFC's support >>multi-threading? > > > This is no different to having any CFM page that takes three seconds > and still being able to support many concurrent users. > > >>3. If they don't, is there something I can tweak/change/do to make >>them better handle near-simultaneous requests? > > > It depends on how you are trying to use CFCs. If you have stateless > CFCs, you can create a single cached issue in application scope and use > that instance for all your cfinvoke's. If you have stateful CFCs, you > need to manage their lifetimes according to whatever rules the state > has - it may be per page, per request, per session. > > Sean A Corfield -- http://www.corfield.org/blog/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
