Can you show us some "before" and "after" code?
Its the same queries that I had on the page are now in a CFC. Do you still need the SQLs? There is absolutely no change in the queries.
Why did you move the queries? Is it so they are available to other pages, or did you do it for philisophical reasons?
Yes, I moved them to a CFC so that the same queries can be made available to other pages. But, I was surprised to see the performance taking a hit.
CFCs do come with a bit of a performance price. How big a hit are you seeing?
Well if the SQL is identical then no need to post it. But everything else in the CFC and the calling code would help.
Okay ... here we go
This is how I invoke the CFC:
<cfinvoke component="dbqueries.iriqueries" method="getRunDetails" returnvariable="qryRunDetails">
<cfinvokeargument name="projid" value="#trim(url.pid)#">
<cfinvokeargument name="runid" value="#trim(url.rid)#">
<cfinvokeargument name="cru" value="#trim(url.cru)#">
<!--- Data display processing --->
<!--- Error message processing --->
And the CFC has following code (I have modified the column names and table names):
<cffunction name="getRunDetails" returntype="query" output="no">
<cfargument name="projid" type="string" required="yes">
<cfargument name="runid" type="string" required="yes">
<cfargument name="cru" type="string" required="yes">
<cfset var qryRunDetails = "">
<cfquery datasource="#mrsdsn#" name="qryRunDetails">
SELECT col1, col2, col3, col4, col5
WHERE trim(pcn) = <cfqueryparam cfsqltype="cf_sql_varchar" maxlength="13" value="#trim(arguments.projid)#">
AND trim(run_id) = <cfqueryparam cfsqltype="cf_sql_varchar" maxlength="20" value="#trim(arguments.runid)#">
AND trim(cru) = <cfqueryparam cfsqltype="cf_sql_varchar" maxlength="20" value="#trim(arguments.cru)#">
AND col9 is null
ORDER BY col1 ASC
<cfcatch type="database"><cfset bError = true></cfcatch>
Note that variables bError and mrsdsn has been declared at the component level not at the method level.
OK, so not really "displaying" the data in the CFC method: just fetching it. I don't see anything suboptimal in your code, anyhow. It's always good to put a second set of eyes on these things though.
As Dan said there is a bit of an overhead instantiating a CFC, but it should be marginal compared to running a DB query.
Can you split your CFC instantiation from your method call and time both separately to see how much overhead the CFC instantiation is actually adding?
Oh, and is "dbqueries.iriqueries" the full path to the CFC from the webroot, or is it relative to your current template or a custom tag path? I guess the question is does CF have to hunt around for the CFC, or is that its explicit path? What'd the relevant dir structure, and where are any mappings or custom tag paths pointing?
- How do I separate the instantiation of CFC from method call? Can you provide help?
- "dbqueries" is the directory directly under "<cfroot>\CustomTags\". So, I do not think CF would take time in trying to locate the iriqueries.cfc file.
Is there a properties and/or xml file that I can read in order to find out what directories CF looks?
Thanks for taking time in helping me.
You can create an object instance with createObject(): http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-69 7b.html
And then you can call its methods as per the example in the docs. It's a bit less clunky than <cfinvoke> IMO.
There's something in the docs about which order CF looks for things in, but I suspect on custom tag paths is going to be one of the last places (found the page: http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec22c24 -7e17.html).
Whilst testing, move your CFC into the same dir structure as your calling code, and see if that improves things. I gotta say I always explicitly path my CFCs, eg: com.mydomain.myapp.somepackage.someCfc, where /com is a CF mapping. That said... I would not expect this to reflect much of a performance hit / improvement.
This thread might be relevent.
Also, to see where the delay is occurring, cfdumping a gettickcount() right before your cfinvoke tag and at various places in the cfc may provide some useful information.
Did you turn debugging on? Coldfusion's debugging apparatus parses and records some administration about all the files involved in a request, from the Application.cfc events fired, through to the objects instantiated and methods invoked.
In general, with debugging on, the CFC will contribute much more to the debugger's consumption than an ordinary CFM page. To compare like with like, switch debugging off before doing any comparison. You may likely find there is nothing wrong with your CFC's performance.
Just a long shot from prior experience:
Does "dbqueries." happen to be a mapping set in CF administrator? I have seen a few times, random, that when its' a mapping, it is a bit slower rather than letting it parse the file/folder path of the webroot. I never could figure it out, but once I had this issue, 2-4 sec difference by having the CF mapping.
No. The debugging is not turned on.
No "dbqueries" is not mapped. Its a physical directory under "<cfroot>\CustomTags\".
No. The debugging is not turned on.
Then turn it on in the Coldfusion Administration. It will display the processes involved in a request and their execution times.
Does this perform any better?
<cfset qryRunDetails = createobject("component", "dbqueries.iriqueries").getRunDetails(trim(url.pid),trim(url.rid),trim(url.cru))>