Jerry,
Can you explain a bit more about how the CFC creation is triggered and
what you mean by many? i.e. Is many 10 CFCs or 500. Several years ago a
developer came into my prior company and believed the idea of OO meant
taking query results and converting each row from a query result set
into an object. He believed he was right regardless of what we told him
until it was load tested. The query returned 1000 results from 30
simultaneous users and the server came to a screaming halt b/c of all
the instantiation. That was in ASP but the same principle applies.
-Jason
Jerry Ela wrote:
A timely question. I have a cfc based app and am being killed by the
time it takes to instantiate the cfcs. I've moved anything I could to
application or session scope, but have a lot of cfcs that need to be
instantiated on a per request basis. I beginning to think I should
change my cfcs into function libraries that modify external data
structures instead of objects that manage instance data so I don't
have to take the instantiation penalty.
I know there are a lot of cfc based frameworks in use and a lot of cfc
based high volume websites that are cfc based, which would tend to say
that using cfcs isn't a totally crazy idea. What kind of a hit do you
see from instantiation as compared to other operations? How many cfc
instantiations is reasonable for a request? Are there server config
issues I should be looking at as a more likely cause of problems than
the fact that I'm using cfcs?
Peter Bell wrote:
Hello All,
Does anyone have any kind of information on the relative expense
(processing wise) of different operations? For example, assuming a
user object has been instantiated, how much more processing does it
take to getUserFirstName() (assuming it is just a "return
THIS.FirstName") versus just using dot notation against the THIS
scoped variable for the object?
If you have a few hundred such operations as page of processing a
page request, would the choice have any substantive affect on
application performance?
I know there are guides on CF best practices for performance (avoid
evaluate, use list compare instead of multiple string comparisons,
etc.) but I can't find a good guide to the relative cost of OO
operations in CF that would help to ensure a design would have a
decent shot at being performant.
Also, while I know it is extremely broad, in general what range of
number of request scoped objects mught you instantiate in a common
page request for a "well architected app"? I'm assuming that it would
be common for a sophisticated page request to instantiate 10-50
objects between the controller, facades, domain objects,
compositional objects and the DAL. Is that a fair heuristic?
Finally, does the physical size of an object (the number of lines of
code across all of the methods) have any substantive effect on
initialization performance (does the entire object get loaded into
memory or are the methods loaded into memory one at a time? For
example, if you have an object with 20 methods each with 500 lines of
code where any given page request may call only one or two of the
methods, would you consider abstracting some of the methods into
separate objects to cut down on object instantion time?
I want to clarify, I'm not trying to shave page processing from 45 to
18ms, I'm just trying to make sure that pages with minimal db and
file system access don't end up taking 300-400ms.
Any thoughts much appreciated!
Best Wishes,
Peter ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject
of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by
CFXHosting (www.cfxhosting.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' as the subject
of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
--
Jason Daiger
URL: www.jdaiger.com
EML: [EMAIL PROTECTED]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
