Good break down on the performance effects of enabling debugging, and I'm glad you've got it figured out too. ---nimer
-----Original Message----- From: St�phane Bisson [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 12:49 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] ColdFusion MX visite SQL 2000 Performance Issues Thanks Christian and Mike, I did my study of what you were telling me. Really interesting. Here what I found out. Problem: A CFC Method is doing a SQL and after that there are CF Codes to loop from that query (200 rows+). In the cfloop I call a persistant (external) CFC methods store in the Application Scope. The SQL is taking 20ms and the call to my facade it's taking about 200-300ms.(in my stupide example) Using getTickCount() before and after the call the the persistant methods is giving me weird result... like... Time to call Application.NumberService.GetNumber is taking 0ms and then on every 7-10 calls it takes 16-20ms... that's why total=200-300ms (this is with the CF Admin option "Enable Debugging" to ON) Using getTickCount() before and after the call the the persistant methods is giving me weird result... like... Time to call Application.NumberService.GetNumber is taking 0ms on all rows... that's why total=20-40ms (this is with the CF Admin option "Enable Debugging" to OFF) So I said to myseft that I should rerun this test on my complex CFC method that contains 5 calls to persistant CFCs in the cfloop with "Enable Debugging" to ON/OFF. With "Enable Debugging" to ON it's taking about 3000ms With "Enable Debugging" to OFF it's taking about 1000ms I used the getTickCount() on each of my 5 calls to persistant methods and I notice that I have one of them that it's doing a SQL call every time! that was taking about +800- ms... so I'm down of about +200-ms to execute my old CFC method. This is very good!. Here the example of what I got.. Call time Country total was: 78 milliseconds Call time State total was: 62 milliseconds Call time Sex total was: 47 milliseconds Call time nore total was: 47 milliseconds Call time online_flg total was: 659 milliseconds <!--- this is my problem is guest!... it's using a SQL the return ---> Call time total was: 893 milliseconds "Enable Debugging" to OFF and using the getTickCount() to figure out why it's taking so long to execute give you the real picture of the performance of your CFC methods. I know now that if I execute a persistant method in my cfloop that it's doing a simple SQL.... it will take to much time to execute... So it's telling me that "Enable Debugging" to ON it's taking like three time slower then if it's OFF to run a CFC method. So for now on, I will test all my CFC methods with "Enable Debugging" to OFF and use the getTickCount() to see the real time it takes to call my methods Now knowing that I could execute my CFC method in 200ms without the 5ft call in the persistant scope and putting "Enable Debugging" to OFF, I don't know if would have done all this de-normalization!... I feel bad to know that after that, because it was taking about 3000ms before I knew that!. > The strange result was: generating new instances were equally fast or > faster than returning just a reference to an existing instance via a > CFC! It appeared that calling the factory method introduced a lot of > overhead. I did the test and it appear that you are right, if my facade instantiate every times my real CFC... instead of taking the persistant one.... it appears that it's about the same result in ms... but every 5-10 times it takes like the double time to execute. So! > #2 - run scenario 1 with 1 change. Put the getNumber() method in the testService.cfc directly. Instead of calling the application.numberservice cfc call the local > copy. I did that test and of course it's really fast... is has fast has a SQL... but you know that it's kind impossible to put every thing in one CFC! Thanks it really help me to understand the permormance issue when I'm calling a CFC method instance in my cfloop that contains many records. Stephane PS: I would like to know more about what is a Factory CFC!! ----- Original Message ----- From: "Christian Etbauer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, August 13, 2003 4:35 AM Subject: RE: [CFCDev] ColdFusion MX visite SQL 2000 Performance Issues Hi St�phane! I would suggest trying to put some output of "getTickCount()" in the code to do the time measuring and run the same example with "report execution times" in CF Administrator turned off. Your description reminds me of problems I had with performance testing of a factory CFC. I generated a few thousands mildly complex CFCs and measured the time taken by using "getTickCount()". Then I kept a single instance of this CFC persistent in application Scope and let it be created by a factory-CFC or return the original instance if already persistent, also for a few thousand times. I wanted to know how much faster returning a reference to an object is over creating a new object. The strange result was: generating new instances were equally fast or faster than returning just a reference to an existing instance via a CFC! It appeared that calling the factory method introduced a lot of overhead. And now this is where it might apply to you: it turned out that enabling the "report execution times" option in debugging in the CF Administrator obviously slows down CFC method calls a lot (in my specific case, at least by the factor 10)! Your description of the example (turning on debugging and calling a rather stupid method) makes me believe you experienced the same effect. -Christian -----Original Message----- From: St�phane Bisson [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 7:09 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] ColdFusion MX visite SQL 2000 Performance Issues Thanks Nathan to point me this... I forgot to deliver the codes to prove what I saw... I worked about 1-2 hours to create this stupide example with two CFCs to show you my ColdFusion MX Scenario #1 (200-300ms) and my SQL 2000 Scenaria #2(0-20ms) ... before they return 200+ rows of results... Scenario #1: is doing a cfloop after the main SQL query and it's calling one CFC methods store in the Application scope to get the stupide number... it's creating a new qery to return also... (200-300ms) Scenario #2: is doing only a SQL and return it(0-20ms) and the SQL has this stupide number already store in the table.... Installation procedure To test Sceniaro #1 1- extract the zip to your site and put request.componentpath in application.cfm with the path of your site 2- Replace in the TestService.cfc the ?table? string with a table that you have that contains 200+ rows 3- Replace in the TestService.cfc and TestCFPerformance.cfm the ?fieldname_name_that_contains_char? string with a fieldname type=char... that you have 4- Run the cfm TestCFPerformance.cfm to see the result with Enable Debuggind to Yes.. 200 ms and more... To test Sceniaro #2, 1- extract the zip to your site and put request.componentpath in application.cfm with the path of your site 2- just read my comments in the TestService.cfc... and uncomment and comment the codes... 3- Run TestCFPerformance.cfm to see the result with Enable Debuggind to Yes.. 10 ms and more... If I remove in Scenario #1 the call to my CFC methods store in the Application scope (I hardcode the value let's say!)... it's about the samething as SQL... of course my method GetNumber is being called 200+ times, but It does not say in the debugging that it take a lot of time!... if you comment the call of my Application CFC instance... you will see a big difference... I just saw that if I call a CFC method in my cfloop... it's taking a lot more time to respond.... even if it's a stupide method... like I have in my example... Stephane ----- Original Message ----- From: "Nathan Dintenfass" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 12, 2003 1:18 AM Subject: RE: [CFCDev] ColdFusion MX visite SQL 2000 Performance Issues > Certainly ColdFusion should not always do what a database can do better, but > I don't think that has anything to do with how many methods you have. From > the sounds of it the overhead is in some CF looping construct that is doing > conditional logic on a string -- so, although CF might have some issue it > doesn't sound like it's a CFC issue. > > But, without any of your code posted here or on the web forums it's not > possible to give truly constructive feedback. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of St�phane Bisson > > Sent: Monday, August 11, 2003 9:09 PM > > To: [EMAIL PROTECTED] > > Subject: [CFCDev] ColdFusion MX visite SQL 2000 Performance Issues > > > > > > Hi gang, I'm writting you tonight because I just thing after having > > created 70 CFC methods... that ColdFusion MX is really not fast > > enough to deliver > > the result.... no body has been taking about that I think...I was > > putting to much of CF codes.... now I use only SQL is the main > > driver because it's so > > fast!... I would like to put more CF codes in my CFC methods... but I know > > for sure, that if I put to much CF codes... it will take to much time to > > execute.... so just read my post and as usual I will be happy to see any > > comments... > > > > http://webforums.macromedia.com/coldfusion/messageview.cfm?catid=3 > > &threadid=670957#2414950 > > > > Stephane > > ---------------------------------------------------------- > 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).
