coldfusioncoldfusion-10cfthread

Is there any benefit to wrapping CFTHREAD around database inserts?


We have a few thousand catalogs with pages that are accessed up to a half a million times each day. At the end of every page hit, we insert some of the CGI variables into a database. If a form was submitted or a search was performed, we insert some of that information to another database. No information needs to be returned from each of these database inserts. These inserts happen at the end of the page processing.

I've read that once a "run" thread is launched page processing continues and doesn't wait for a response. This seems like it would speed up the page being complete because it's not waiting for the queries in the pages to run. Is this correct?

Is there any benefit to putting these database inserts into their own thread like this?

<cffunction
    name="OnRequest"
    access="public"
    returntype="void"
    output="true"
    hint="Fires after pre page processing is complete.">

    <cfargument name="RequestedContent" type="string" required="true" />


    <!--- OUTPUT THE PAGE CONTENT --->
    <cfinclude template="#ARGUMENTS.RequestedContent#" />

    <cfscript>
        thread
            action="run"
            name="Tracking" {
            include "track1.cfm";
            include "track2.cfm";
        }
    </cfscript>

    <cfreturn />
</cffunction>

Solution

  • I would say "no, there is [little] benefit in doing that". You'll save your user a few more ms, but you'd put your ColdFusion server under twice as much load, which in turn might cause a performance hit across the board. The server only has a finite number of threads available to use for all requests, so doubling the number you use for each request is gonna double the risk of using 'em all up.

    Also starting a new thread has overhead in itself, so the gain you're giving your users here would not be linear.

    If your insert queries are taking long enough that they are impacting your user experience, then what you should be doing is tuning those (at the DB end of things).

    Also: unless you have a performance bottleneck on that code already, there's not really much point in prematurely optimising it.