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).

Reply via email to