speed up CFHTTP on CF10 (5000x slower than under CF8)

[jdbo]

Hi, we've just moved a large application from CF8 to CF10 and are seeing that CFHTTP performance is *much* slower on the new system.

We've verified this by sequentially running 50 CFHTTP calls to small static assets on an Apache server, measuring the response times with gettickcount(), and averaging over several runs.

On our old (Ubuntu + JRun + CF 8) installation, we're averaging about 1 ms per request.

On our new (Centos + CF 10 standalone) installation, we're averaging 5000 ms per request. That's 5000 times slower.

We initially suspected that this was related to entropy generation issues as the first request in a test run would return relatively faster (a few hundred ms in total) compared to all subsequent requests in that run.  However, attempting to modify the JVM settings as prescribed did not resolve the issue.  We've further tried using alternative entropy-generating tools (as recommended in the original blog post cited in the aforementioned thread), but that has not helped either.

Note that we've also tested http performance outside of CF by using wget from a shell script, where we saw good performance (approx 1ms per request).

All help on this issue will be greatly appreciated, thanks!

Update: just tested the CF+Java-based CFHTTP alternative http://coldfusion9.blogspot.com/2012/03/custom-cfhttp-tag.html

It required a few minor bug fixes, but is greatly outperforming CF 10's CFHTTP, averaging 33 ms per request (still much slower than CF 8, but usable for most purposes).  Nonetheless, I'm still looking for a fix to restore appropriate speed to CFHTTP!

Message was edited by: Jon Obuchowski to add testing with custom CFHTTP tag

[James Moberg]

Could you post the code that you used?  I'd like to test it against ColdFusion 8, 9, 10, 11 (Windows) and the current version of Railo to see if there's any performance hit.

I also plan on comparing it against CFX_HTTP (Windows; C++; 32/64bit) as I've previously run into some issues that Adobe BugBase has officially responded with "Won't Fix; Upgrade and Hope We've Fixed It In the Next Version".  (As a result of the reported CF9 CFHTTP bug, one major financial gateway silently updated their website and removed all documentation & support for ColdFusion.)

[jdbo]

Hi, the original code (which is really simple) references locally hosted assets so I've created a stripped-down version where you can define your own assets to test with.  Thanks for doing this!

<cfsetting enablecfoutputonly="yes">

<!---
  FILE: chttp_performance.cfm
  ABOUT:  simple performance testing for CFHTTP
          50 static assets between 10 and 100 kb are retrieved to test request/response time
--->

<cfsetting requesttimeout="480">

<!--- ********** --->
<!--- ********** --->
<!--- UPDATE THIS EXAMPLE LISTING WITH 50 URLS TO STATIC ASSETS SIZED BETWEEN 10 AND 100 KB --->
<!--- ********** --->
<!--- ********** --->
<cfset variables.assets = [
  "http://example.com/media/data/media_000000002578.pdf",
  "http://example.com/media/data/media_000000005712.pdf",
  "http://example.com/media/data/media_000000006362.jpg",
  "http://example.com/media/data/media_000000006417.jpg",
  "http://example.com/media/data/media_000000006424.doc",
  ]>
<cfset variables.total = arraylen(variables.assets)>

<cfset variables.timeout = 30>

<cfoutput>
  <h1>CFHTTP performance testing</h1>
  <p>
    Calling cfhttp #variables.total# times (using a #variables.timeout# second timeout)...
  </p>
</cfoutput>
<cfflush>

<cfset variables.timings = arraynew(1)>
<cfset variables.sum = 0>
<cfoutput><ol></cfoutput>
<cfloop array="#variables.assets#" index="variables.asset">
  <cfset variables.u = variables.asset>
  <cfoutput>
    <li>
    Getting #variables.u# ...
  </cfoutput>
  <cfflush>
  <cfset variables.start = gettickcount()>
  <cftry>
    <cfhttp
      method="get"
      url="#variables.u#"
      timeout="#variables.timeout#"
      >
    <cfcatch>
      <!--- fail silently --->
    </cfcatch>
  </cftry>
  <cfset variables.duration = gettickcount() - variables.start>
  <cfoutput>
    done in #variables.duration# ms
    </li>
  </cfoutput>
  <cfflush>
  <cfset arrayappend(variables.timings, variables.duration)>
  <cfset variables.sum = variables.sum + variables.duration>
</cfloop>
<cfoutput></ol></cfoutput>
<cfset variables.average = (variables.sum / variables.total)>
<cfset variables.min = arraymin(variables.timings)>
<cfset variables.max = arraymax(variables.timings)>

<cfoutput>
  <p>
    Total cfhttp calls: #variables.total#
    <br/>
    Average: #variables.average# ms
    <br/>
    Minimum: #variables.min# ms
    <br/>
    Maximum: #variables.max# ms
  </p>
</cfoutput>

<cfsetting enablecfoutputonly="no">

[James Moberg · Accepted solution]

Thanks.  I modified the code and added 2 additional calls for the HTTPRequest CFC and CFX_HTTP5.  (I also had to modify the CFC to enable requests without passing URL/Form vars.)

I tried this on ColdFusion 8, 9 & 10 running on Windows.  I pulled 50 files from 5 different internal web servers.  (DISCLAIMER: The specs are not the same for each CF server.)

Here are the averages.

ColdFusion 10   CFHTTP: 9.04     CFC: 18.14       CFX_HTTP5: 1.26

ColdFusion 9     CFHTTP: 8.08     CFC: 158.92     CFX_HTTP5: 2.4

ColdFusion 8     CFHTTP: 4.86     CFC: 149.14     CFX_HTTP5: 2.14

I posted a blog entry regarding this and shared the CFML that I used to compare the performance:

http://gamesover2600.tumblr.com/post/88683513184/coldfusion-cfhttp-versus-httprequestcfc-versus

[Steve Sommers]

Since you're using GET in your cfhttp tag and you're not specifying no-cache anywhere or using other cache defeating techniques, could caching be a factor in your results? I use CFHTTP quite often in CF9-10-11 and never noticed anything close to a 5000 ms overhead.

[jdbo]

Thanks!  Our setup uses the above test script to targets static assets on the same server that CF is running on (which isn't running any sort of cache), so I don't see how that would be a factor in this case.

Also, I should also point out that the alternate tests run on the same server and target the same assets, so I think these would be affected by the same caching issues if those were a factor.

Of course, I could be overlooking something, if you have any particular suggestions to look into.