Invocations are cheap (as long as you turn debugging off). However, instantiation can be expensive, so as long as you're caching your CFCs in the application or server scope, you should be fine. Even with simple Mach-II apps, 50 CFC invocations happens all the time, but for Mach-II, literally everything is in the application scope.
I'd be a little concerned about how you're caching your database in the application scope, however. That's just asking for trouble, IMHO. At the very least, you should use a revolving cache, so it caches the X most recently used objects, rather than all of them. You probably want to look at the build in query caching, and/or DB-level caching, as they'll probably be a lot better suited for a loaded app. Of course, I've got no familiarity with your app, so you have to make the call. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Alex Gadea > Sent: Wednesday, December 03, 2003 11:24 AM > To: [EMAIL PROTECTED] > Subject: [CFCDev] Is 50-70 cfc invocations per page crazy? > > We are in the process of architecting a large CRM system. > It's architecture > is heavily CFC based and I am beginning to have some concerns > as to whether > what we are doing might be a tad bit crazy in terms of > performance under > load. The app stores all aspects of a screen in a database > for rendering > upon user demand. So, a user can, for example, build a table > on the screen > by inputing the data within the database and then the app > will query the > database for the table definition and then render that to the > screen. Every > aspect of a screen is stored as an XML object in a database. So, for > example, one HTML table on a screen will have multiple > objects that define > it. The table object and its children are a good example of our > architecture. The objects that make up our "screen table object" are > defined as follows: > > 1) table object - contains data describing the overall table > 2) column objects - data that describes each column in a single row > 3) data objects - data that describes the data that is > available to the rows > 4) filter objects - data that can be applied to the data > object to further > narrow its scope > 5) menu objects - each row of the table has a popup menu that further > defines what actions can occur against the row > > Anyway, we have about 10,000 objects and instead of querying > them from the > DB every time we want to draw something on the screen, we > simply store all > the XML fragments in an application scoped CFC and then > retrieve the data > from this CFC. This CFC seems to increase the system memory > by about 150MB > and is extremely responsive for returning the data objects > that we have > stored. Anyway, each of the objects I described above have CFCs that > define them (sometimes the CFCs are extensions of other CFCs > such as the > table menu object which is an extension of our standard menu object). > Within the CFC we do basic stuff like business and security > validations but > we also build the HTML for that particular object - I know > the lack of > separation from the HTML display is frowned upon but it made > sense for our > app. > > So, using the above example, the following CFCs would be > invoked for the > creation of one table on a screen and stored in the request scope: > > - 1 table CFC > - multiple column CFCs - one for each column of the table with tables > usually having 3-10 columns > - possibly multiple data CFCs although there is usually only > 1 for a table > - multiple filter objects - average about 10 per table > - multiple menu objects - usually 3-5 per table > > A screen as a whole may have 2-3 tables, so as you can see, > there could > possibly be 50-70 CFC invocations for one page. We have done > some load > testing (up to 10 concurrent requests) and did not see any > degradation in > speed. Each page takes between 450-1000ms to render which is > acceptable for > our app. > > So my big question is whether the number of CFC invocations > (50-70 per page) > that we are making into the request scope are going to come > back to haunt us > as we scale out. > > thanks, > > Alex Gadea > Apptik Inc. > ---------------------------------------------------------- > 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]
