Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

The server is under pretty much load - few hundred requests per second. Vast majority of them is through SSL.

The problem is that first request through HTTPS to the server meets very slow response (like 10s) even if database is not involved. Next requests are realized in eye blink. At the same time without SSL it works fast constantly. Few days ago situation was inversed - most of the traffic was without SSL ant then it was fast without SSL and with SSL slow.

I want connections to go through SSL but the first reponse after some time of lack of activity at level of about 10 seconds is unacceptable. What could I change in probably apache2 config to avoid the first slow response?

share|improve this question

4 Answers 4

It sounds like you are CPU bound on the key exchange. Common problem. When a client connects over SSL/TLS for the first time a (very computationally expensive) key exchange is made. After this key exchange has been completed the clients can reuse the keys obtained in the exchange in the following communication. This is why the first request over HTTPS takes so much time to complete.

There is very little you can do about this situation, other than adding resources. More CPU will speed up the calculations of the key exchange. More memory is always good. You can also configure Apache to keep generated keys in memory for longer, to avoid having clients redo the key exchange.

You could also get some marginal improvements to the performance by changing cipher suits or tweaking keylengths, but it is usually not worth the hassle.

If you are going to be running over this kind of load for a longer time it may be a good idea to offload the SSL/TLS calculations. You can get a separate box (using your favourite proxy), a SSL acceleration card or even a specialized SSL/TLS offloading box.

share|improve this answer
    
It may be it, but why CPU usage is so low(150-200% / 1600%)? –  Joe Sep 4 '13 at 14:00
    
It seems it is not related to HTTPS. I switched traffic to pure HTTP and initial slow still exists. This problem really is killing me. –  Joe Sep 5 '13 at 7:04
    
If it's still slow on HTTP you can ignore this. Then I would suggest looking at DNS as @GioMac suggested. I must have misunderstood your question. –  pehrs Sep 5 '13 at 8:48
1  
I have found a problem. I had to turn off the KeepAlive. There were to many new connections and acutally most of them wasn't long enough to keep the KeepAlive on. I trurned it off so now the connections are not blocked. –  Joe Sep 5 '13 at 10:06
1  
Post your answer here, so we can close the question with a good answer. ;) –  pehrs Sep 5 '13 at 10:15

Looks like DNS issue. Check that DNS is configured on localhost and working properly, also, check HostnameLookups directive is set to off in apache configuration.

share|improve this answer
    
Would requests on HTTP still be fast if DNS is failing? –  pehrs Sep 4 '13 at 13:32
    
Maybe. I don't think that key exchange calculations take 10s. Even with 2048 bits –  GioMac Sep 4 '13 at 13:33
    
My experience is that key exchange can take a very long time on servers where the CPU load is too high, as the key exchange is several orders of magnitude more expensive than serving a normal request. –  pehrs Sep 4 '13 at 13:38
    
This is 4096 SSL. HostnameLookups is set to off. This is default LAMP installation during ubuntu installation so I guess localhost is set fine. I changed only MaxRequestsPerClient to 20000 in mpm sections. –  Joe Sep 4 '13 at 13:40
    
@pehrs - cpu load is low its 150% on 1600% available. –  Joe Sep 4 '13 at 13:40

There are two scenarios I can think of:

  • Check Apache's logs and make something clever out of it (errors, access logs timestamps, etc) - this is a longshot I think
  • Or: I suggest you to Wireshark how the SSL handshake protocol goes. You should see where the 10s elapses - on server side or on client side. I guess opening the keystore or something like that takes up a lot of time, but at first you should sniff the network traffic for timestamps. Let us know how it went!
share|improve this answer
    
I'll try to check your suggestion altough I'm not sure whether it is SSL handshake problem. As I wrote in question when all traffic was without SSL - https was fast and http was slow. –  Joe Sep 4 '13 at 13:43
    
As this is really just asking for more information it might be better as a comment. –  Drew Khoury Sep 5 '13 at 3:39
    
Due to lack of reputation, I couldn't do that, but I totally agree with you. –  David Sep 5 '13 at 8:34
up vote 0 down vote accepted

I have found a problem. I had to turn off the KeepAlive.

There were plenty of new connections every second (200-300/s, sometimes more). Most of them didn't need the connection to be kept alive for 5 seconds. As a result connection pool was quickly utilized and all new connections had to wait for the old one to terminate after the 5s.

It appears KeepAlive option is useful only when server is able to hold enough opened connections while most of users do sth for specified by KeepAliveTimeout parameter (like 5s in my case).

Other case it is actually useful to turn it off.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.