2

I've heard that CFHTTP calls that point to a local server can cause additional delays for the user. As this is a HTTP request, it seems to me that any delays would be negligible - though I don't know a whole lot about networking/systems and load-balancing.

Are there any downsides/cons to using CFHTTP to make local calls and if so, are there ways to mitigate those?

joncarlson
  • 165
  • 8
  • As a use case, we have legacy code that logs users in and then does a cflocation to redirect to a supplied URL with either an error code or a success code defined. We wanted to make use of this code without editing it so instead we are doing a CFHTTP and setting the redirect to go to our own processing page, which spits back a response. This login code is normally used via a cfinclude, so it's on the CF server itself - as it's login code, it's also only called on signon, not on every page load. – joncarlson Nov 26 '12 at 14:46

3 Answers3

2

What is it that you're trying to do with these HTTP calls? If whatever you're fetching by HTTP is on the local file system, actually using the file system (fileRead(), include, etc) rather than the network to get them will be more expedient.

That said, if you do actually want to perform a request for whatever reason (which is completely legit in some situations), then I don't think the performance overhead would be something to worry about. Although I'd not want to be doing this sort of thing on every onRequestStart(), etc.

I think you need to elaborate on what it is you're setting out to achieve here.

Adam Cameron
  • 29,677
  • 4
  • 37
  • 78
  • Added a comment above with our exact scenario. As in the reply to barnyr, I agree an include would definitely be preferable. In the current situation, if the overhead is minute, then we could go with it as is for now, with the goal of replacing it later. – joncarlson Nov 26 '12 at 14:53
1

it seems to me that any delays would be negligible

Perhaps, it would depend on your traffic and any other latency problems you're having. I did a simple test that fetched 5 paragraphs of pre-generated Lorem Ipsum dummy text that was served from the same CF server. The result took between 15 to 47 milliseconds, which as I said, depends on you to decide if it is negligible. Personally I think it's a bit high but from a user perspective, it wouldn't be noticeable in my environment.

As far mitigation, if you're trying to re-use code I'd consider putting your authentication into a cfc. This is beneficial because you can use it in multiple local applications as well as a web service if needed (which is technically what you're trying to do by using cfhttp).

What is the problem with including the process in a cfinclude as you said you were doing before? testing proved including the same pre-generated Lorem Ipsum text took 0 MS every time.

<cfset start = getTickCount()>
<cfhttp url="http://myServer.com/test/lipsum.cfm" method="get" >
<cfset end = getTickCount()-start>
<cfoutput>it took #end# MS to get the Lipsum.</cfoutput><br />
<cfset start = getTickCount()>
    <!-- <cfinclude template="lipsum.cfm"> -->
<cfset end = getTickCount()-start>
<cfoutput>it took #end# MS to include the Lipsum.</cfoutput>

it took 43 MS to get the Lipsum.
it took 0 MS to include the Lipsum.
genericHCU
  • 4,394
  • 2
  • 22
  • 34
0

You don't specify whether you're calling back into the ColdFusion server itself or another service hosted locally. It might help to expand the question a little to provide a use-case.

The speed penalty of calling a local server will be relatively small and in some cases that may be fine, e.g. making a call to a local Solr server to get search results. It will however likely be much slower than calling a function locally within CF.

What I'd be concerned about would be calling back into the server you are executing the ColdFusion on. This is probably a sign that things could be better organised or arranged. I've done this in the past (as a cheap'n'cheerful way of running a background task), but wouldn't do it now that <cfthread> exists.

barnyr
  • 5,678
  • 21
  • 28
  • Thanks, I added a comment to further explain the situation. The ideal solution I agree would still be rebuilding the code we're using to be a function, but due to time constraints we're having to use the code as is for now. – joncarlson Nov 26 '12 at 14:50
  • 1
    If the code can successfully be called with a cfinclude, why not simply do that? It sounds like you are trying to fix something that ain't broke. – Dan Bracuk Nov 26 '12 at 16:20