On Thursday, January 27, 2011 11:24 AM, >Am 27.01.2011 16:34, schrieb Matus UHLAR - fantomas: >> On 22.01.11 00:53, john.3.newton@xxxxxx wrote: >>> >>> We recently moved our production webserver from a sparc platform (T2000) >>> to an x86/64 platform (x2270-m2) and we have noticed an erratic response >>> time for downloads of files using SSL. This seems to randomly occur with >>> any files about 10k or larger. For instance, I have been using a test file >>> of 140K, and it can take 0.5 or 4.8 seconds to transfer. When using the >>> sparc platform, it always only takes 0.5 seconds. >>> >>> I noticed this as we are using an external monitoring system (Gomez.com) >>> and we started seeing these wildly varying times for transaction >>> processing. >>> >>> I have tried a cut down SSL setup for testing, and examined every >>> directive and option, and I can't make sense of the problem. I'm using the >>> following configuration string, and I'd be happy to include the >>> configuration setups.. >>> >>> I can move the bare-bones configuration between the sparc and x86 >>> platforms and get normal response on the sparc, and irregular on the x86. >> >> random device can make a huge difference. What do you use for random data? >> /dev/random or /dev/urandom? If the rofmer, try the latter if it helps. > >Good point. But to have some prove at hand, don't change the random >device yet - instead monitor /proc/sys/kernel/random/entropy_avail with >e.g. watch. If your're going of of random bytes - ka-ching :) > >Regards, >Edgar Good idea. I was wondering if not enough entropy was the problem, but didn't know how to verify that. I'll give your suggestion a go when I'm testing connections next, and see what it does. Thanks for the suggestion, and I'll let you know what I find out. John Newton --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|