Did you actually load test the application? If so, can you please provide us with the data obtained from the test e.g. how many simultaneous users receive what average response time, etc.
Further, it is a wrong assumption to determine what type of applications I like to build based on my comments about using CFCs in certain use cases. I find that many people like to move the debate away from technical issues by involving me personally in the debate. An Ad Hominem is a fallacy and thus not a valid position from which to debate. Why someone would choose that type of position is an exercise for the reader. Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Benoit Hediard > Sent: Thursday, March 27, 2003 6:13 PM > To: [EMAIL PROTECTED] > Subject: RE: CFC scalability problems (was : RE: [CFCDev] MVCF at > benorama.com) > > Some results of quick load testing on my dev notebook with the beta > version > of our application. > > Hardware : PIV 2Ghz, 512 Mo Ram, IDE disc > Software : (all on the same machine) > - WinXP Home > - Apache 2.0.44 > - Jrun + CFMX for J2EE developer edition > - SQL Server 2000 SP3 > Application : ~70 CFCs, ~200 tables in DB, based on MVC with CFCs used on > the Model layer (stateful CFCs and database persistent CFCs), views and > controllers are CFMs. No java at all. > > The typical page requests time is around 130ms to 150ms, fully dynamic > (without any caching mechanism activated). > On a "real" configured production server (with a separate DB server), it > should be better (not even talking with caching on). > > I am not saying that CFCs are better than pure java for the model layer. > If you can pay the price of Java (in terms of ressources, knowledges and > development time), it will be better for performance and scalability. > But for many CFMX applications, java is not required, CFCs can do really > well the job and are going to be much more productive. > > Matt, you like to build "Ferrari" type applications, and you're probably > excellent for that, java will allow you to build and to tune your own V12 > engine very well. > For most of us, "Porsche" type applications are already well enough and > we're happy with our standard flat-six... ;) > > Benoit Hediard > www.benorama.com > > > -----Message d'origine----- > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la > > part de Matt Liotta > > Envoye : jeudi 27 mars 2003 16:34 > > A : [EMAIL PROTECTED] > > Objet : RE: CFC scalability problems (was : RE: [CFCDev] MVCF at > > benorama.com) > > > > > > Well if you feel that 50pps or even 10pps is enough; show me an > > application with persisted CFCs that achieves that. Remember, to achieve > > 10pps you need all page requests to be handled in 100ms or less. > > > > I invite everyone to go and test persisted CFCs and see for themselves. > > See what kind of pps you can achieve and decide if that is enough for > > you. > > > > Matt Liotta > > President & CEO > > Montara Software, Inc. > > http://www.montarasoftware.com/ > > 888-408-0900 x901 > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf > > > Of Benoit Hediard > > > Sent: Thursday, March 27, 2003 10:11 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: CFC scalability problems (was : RE: [CFCDev] MVCF at > > > benorama.com) > > > > > > Matt, the biggest complaint you're always talking with CFC is > > "overhead". > > > But, not all of us are targeting the holy grail of 100pps (page > > requests > > > per > > > second). > > > > > > Sometimes, 50 pps or even 10pps will be enough, for example, on > > intranets > > > B2E/B2B applications with 100 to 1000 users (majority of company > > > applications). > > > Hardware costs are usually peanuts compared to development costs. > > > > > > Scalability (at the level you're trying to reach) is becoming an > > important > > > issue mainly on very large B2C applications where hosting costs and > > > hardware > > > are an important part of the business model. > > > > > > So, OK, CFCs might add some overhead, but this do not prevent most of > > us > > > to > > > build nicely architectured CFMX applications heavily based on CFCs, > > with > > > MVC, persisted CFCs... > > > > > > My 2? cents... ;) > > > > > > Benoit Hediard > > > www.benorama.com > > > > > > > -----Message d'origine----- > > > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la > > > > part de Matt Liotta > > > > Envoye : jeudi 27 mars 2003 14:33 > > > > A : [EMAIL PROTECTED] > > > > Objet : RE: CFC scalability problems (was : RE: [CFCDev] MVCF at > > > > benorama.com) > > > > > > > > > > > > > The specific situation, as I recall, was where you try to map > > between > > > > a > > > > > pure object representation and a relationship representation - > > when > > > > you > > > > > try to have a CFC which has an instance variable for each column > > in > > > > the > > > > > row. There is quite a bit of overhead involved in marshaling your > > > > query > > > > > to and from a series of discrete variables. As noted elsewhere, if > > you > > > > > try to do this by writing generic code that uses cfproperty to > > > > describe > > > > > the instance data, then you're adding a lot of overhead! Of > > course, > > > > you > > > > > don't have to do it this way... > > > > > > > > > Mapping from a relational representation to an object representation > > is > > > > one example of overhead associated with persisting CFCs. However, I > > was > > > > referring to the generic needs to getting instance data from one > > source > > > > be it a table or a file and then setting the needed variables in the > > > > CFC. Certainly, doing this with some generic code seems to be the > > > > slowest option, but even doing it at all seems to add quite a bit of > > > > overhead. > > > > > > > > As far as I can tell, there is no way around setting each of the > > > > instance properties individually, so please do explain another way > > to > > > > accomplish this. > > > > > > > > -Matt > > > > > > > > ---------------------------------------------------------- > > > > You are subscribed to cfcdev. To unsubscribe, send an email > > > > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > > > > in the message of the email. > > > > > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > > > by Mindtool, Corporation (www.mindtool.com). > > > > > > > > > > > > > > ---------------------------------------------------------- > > > You are subscribed to cfcdev. To unsubscribe, send an email > > > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > > > in the message of the email. > > > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > > by Mindtool, Corporation (www.mindtool.com). > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email > > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > > in the message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
