Unfortunately, all the CFCs get invoked at the request level since each object is going to be different for each page request. We thought this was better than dealing with potential locking issues at the app level. Since the CFCs are so closely tied with the actual HTML generation they really just need to be destroyed after the page is created. Its good to know that the number of invocations is not completely out of the ordinary. Whew ;)
As for the DB, I do see your point and it is one of our concerns. It is architected so we can pretty quickly fine tune the caching. The load level of just returning the XML from the mssql database was so large for even simple pages that we saw no other option other than retrieving everything once, parsing out all the XML, than loading it into a application level struct. It's pretty much read only (50,000 reads to 1 write) once the initial struct is created so our locking issues are not much. So far it looks very good under the initial load we have it placed under but it is one of those things that we are waiting to have to redo at some point once we get a feel for how it reacts under real user scenarios which never seem to mimic what we come up with in the lab (now why is that ...). We've built the CFC that reads and writes the data to be pretty flexible in case we do have to go back and rearchitect this part of the system. Thanks for the advice. Alex ----- Original Message ----- From: "Barney Boisvert" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 03, 2003 2:36 PM Subject: RE: [CFCDev] Is 50-70 cfc invocations per page crazy? > 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] > ---------------------------------------------------------- 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]
