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]
