4

I'm trying to debug a problem with SSL in Apache. I've used Wireshark to capture the packets, and I see the client hello message go out, and then about 10 seconds or so later, I get back a server hello. Once the SSL connection is established, subsequent HTTPS request are faster.

I am using /dev/urandom for entropy, and I think I have plenty available. My CPU load is next to nothing, but I receive about 10 requests/second.

I'm using the stock settings in Apache 2.2.14 on Ubuntu 10.04. My certificate is a SAN certificate from GoDaddy.

What steps should I take to find out why my server takes so long to respond over SSL? HTTP is snappy, but HTTPS is dead slow.

Edit:

Here is an image that shows the client hello, and then about 10 seconds later, the server hello:

enter image description here

Improve this question
4
  • FYI: Apache 2.2.14 is 3 Years Old has quite a few known vulnerabilities. You should strongly consider upgrading to 2.2.23 (or the latest version available from your distro). Commented Dec 18, 2012 at 16:54
  • What does cat /proc/sys/kernel/random/entropy_avail report? Commented Dec 18, 2012 at 16:55
  • @Chris S -- what information does that provide an administrator? Commented Dec 18, 2012 at 19:28
  • 2
    entropy_avail is the number of bits of random data available. It should be in the 2000+ range for a normal server. Being under 200 is very near "running out" for a SSL server that commonly requires 64-128 bits of random data per new connection. There's quite a few articles around for gathering more entropy. I'm not sure if Linux uses hardware sources by default, I've seen more than a few articles about daemons necessary (at some point in time) to gather entropy from hardware sources. urandom is the non-blocking entropy souce, but I'm not sure OpenSSL will use it... Commented Dec 19, 2012 at 13:50

2 Answers 2

Reset to default
1

Increasing MaxClients will most likely fix this problem.

Note that the default value for MaxClients IS 256, so if this change took care of the problem then you probably had a setting for MaxRequestWorkers that was something lower. Note that MaxClients is the deprecated name and MaxRequestWorkers is the new name, so if you had a smaller MaxRequestWorkers then added a MaxClients later down in the config, the MaxClients value would override your lower MaxRequestWorkers value, fixing the problem.

As far as why this only happened on HTTPS, I suspect it's because browser clients are more aggressive at keeping connections alive when on HTTPS (understandably). So it is much easier to run out of available clients.

Improve this answer
0

I bumped up the MaxClients in the apache config to 256, reloaded apache, and things improved dramatically. I'm having a hard time believing that was the problem because HTTP was snappy as ever, but HTTPS was slow.

apache2ctl status reports "185 requests currently being processed", and the MaxClients setting was 150 before I made the change. So it kind of makes sense, but again, why would HTTP be fast?

cat /proc/sys/kernel/random/entropy_avail reports 190.

Apache 2.2.14 is the latest version of apache available for Ubuntu 10.04.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.