CFHTTP: first request fast, following slow
Asked Answered
A

1

8

I'm having a lot of trouble with CF10's CFHTTP at the moment.

First, my test script:

<CFSET results = arraynew(1) />
<CFLOOP from="1" to="10" index="idx">
    <CFSET timer_start = getTickCount() />
    <CFHTTP url="https://www.google.de" method="get" result="test" />
    <CFSET arrayappend(results, (getTickCount()-timer_start)/1000 & " s") />
</CFLOOP>
<CFDUMP var="#results#" />

10 CFHTTP calls in a row, the time they take gets pushed to an array; that's all.

Results of our CF9 server:

CF9 CFHTTP TEST RESULTS

Results of our CF10 server:

CF10 CFHTTP TEST RESULTS

Results of our CF10 server with 5 sec delay between CFHTTP calls:

CF10 CFHTTP TEST RESULTS WITH DELAY BETWEEN CALLS

I already read on the forum and Shilpi's Blog that the reason could be that the Linux server runs out of entropy. I checked that with watch --interval=0.1 cat ... while my test script ran but it never dropped far under 4k (with rngd already installed).

Does anybody has another idea what I could try to fix this problem? Using /dev/urandom seems to be an insecure hack to me; so that's not an option (since CF10 server is production machine).

Thanks guys!

Abduce answered 4/10, 2013 at 14:33 Comment(3)
The server is running the latest CF10 update 11, right?Spearman
Yes, that's right. OS is CentOS 6.3. Java version is 1.6.0_29.Abduce
They are no longer maintaining Java 1.6, you should update to version 1.7. Not sure if that will have any affect on your issue though.Mantissa
C
4

While making a cfhttp call to a coldfusion server the apache httpclient library tries to generate a secure random number. It is an operation which depends on the "entropy" of the system.

In case of linux systems (mainly the ones which are freshly installed) it is observed that this operation can be quite time consuming because the system "entropy" is apparently quite low. Hence, as a consequence cfhttp calls will be slow.

Source: http://blogs.coldfusion.com/post.cfm/optimizing-cfhttp-calls-on-linux-systems

Solution: Add “-Djava.security.egd=file:/dev/./urandom” to your jvm-setting.

In the Adobe Forums, you find another thread with your problem and the same solution and a following link with further informations about the random number generator: http://forums.adobe.com/thread/1063806

There is no need for not using /dev/urandom as it is a secure solution: https://security.stackexchange.com/a/3939

Crosby answered 8/10, 2013 at 12:38 Comment(4)
The OP has already stated in the question that they do not want to use the /dev/urandom option. They are looking for another solution.Mantissa
Security expert from Adobe wrote on her blog: "Note: #1 is the best solution and most secure. However for development phase and test environments (even for systems where you are ready to compromise on security), #4 solution is what I used and I recommend." where #1 is using something like rngd and #4 is using /dev/urandom. (shilpikhariwal.com/2012/04/…)Abduce
Thomas Pornin (the author of the answer da_didi links to) is a professional cryptographer - go look through his responses on security.stackexchange.com for his qualifications. If he's saying /dev/urandom is secure, then I'd ask anyone who disagrees to demonstrate why they believe him to be incorrect.Spearman
In the article that @Abduce referenced above she even states that /dev/urandom is secure. From that page: while /dev/urandom will always provide random bytes though they may become of a lesser quality once the initial buffer is outrun. However note that I am not implying that it is not secure at all.Mantissa

© 2022 - 2024 — McMap. All rights reserved.