问题
I have a dedicated server with 256GB RAM 6 CPUs (12 Threads) on Hetzner, and it is located in Germany. I have CENTOS 7.5. EA4.
My problem is with SSL. Every day for about 2 hours, we have 40 requests in one second and finishing requests takes about 20 seconds. Non-SSL takes 0.5 or less. Here is an example.
From 13:00 to 15:30 (UTC+4), SSL requests take the most time. The problem is evident when you open this link with SSL and without.
I have WHM available. I've noticed ModSecurity and wonder if it might be the problem. I've applied most of the settings provided here, but there is not much regarding SSL.
In case certificates are the reason for all of this:
回答1:
Modsecurity might be a problem, if it takes up a lot of CPU and competes with TLS (although the probablity is not huge).
The key is "Every day for about 2 hours we have 40 requests in one second and at that moment finishing requests takes about 20 seconds sometimes." There is something happening on this server at that time that (probably) makes the CPU loaded (since making a HTTPS connection is CPU intensive). So please inspect your server at the time when this happens. This will be your bottleneck of performance.
Another point - consider that maybe something is happening on the network from Pingdom to your server so benchmark with curl when the problem is happening like so:
x@517713:~$ curl -w "TC:%{time_connect} TST:%{time_starttransfer} TT:%{time_total}\n" https://blog.x.cf -D /dev/null -o /dev/null -s
TC:0.005 TST:0.336 TT:0.377
These are all the options:
time_namelookup: %{time_namelookup}\n
time_connect: %{time_connect}\n
time_appconnect: %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_redirect: %{time_redirect}\n
time_starttransfer: %{time_starttransfer}\n
----------\n
time_total: %{time_total}\n
There are so many options of what can be wrong that you should start by identifying where the problem lies: Pingdom, Network, You server.
Once that is done - dive deeper. Let's say it is your server that is misbehaving: - Check the server logs - they should have something in them durring that time; - Consider turning OFF modsecurity (which is very CPU intensive); - Turn on caching on the server; - Consider load balancing between 2 servers; - Maybe the disk is slow - check that.
P.S. Solution that solves the issue 100% is hard since not a lot of details is provided for that.
回答2:
So far I am unable to reproduce your problem. WebPageTest reports are all good and pretty. SSL negotiation is within expected 100-200 ms considering you have OCSP stapling enabled. It would have been taking longer under IE otherwise. Suffice to say HTTPS is always slower at first than a plain HTTP, you can't really compare them. All of which makes me think that...
One possible culprit is the mentioned OCSP stapling. What OCSP stapling on your server does is from time to time your server contacts your CA to receive a signed OCSP response. In this situation your CA could be the bottleneck. If it can't provide an expected response on time, you connection stalls too, and that would happen exactly when you're seeing it: during SSL negotiation.
You can check for how long a cached OCSP response is valid with the following command:
openssl s_client -connect banners.analyticson.com:443 -status -servername banners.analyticson.com
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Produced At: Jun 17 21:47:34 2018 GMT
Cert Status: good
This Update: Jun 17 21:47:34 2018 GMT
Next Update: Jun 24 21:47:34 2018 GMT
Currently it reports that an OCSP response is valid up to Jun 24 21:47:34 2018 GMT at very least, but Apache is configured to expire them quite earlier by default. Specifically after just one hour. You should try raising this timeout to a more meaningful value, like up to a week:
SSLStaplingStandardCacheTimeout 604800
Another possible advice is a contrarian one: try disabling OCSP stapling altogether for some time.
If this would really help to remove the problem, then you should be either contacting your CA for assistance, or switch to use a different CA known not to have such problems (think Let's Encrypt), or use a different webserver that can handle OCSP stapling asynchronously and cache them for a longer time (think nginx).
Further research shows that Apache can be made to work around slow or unreliable OCSP responders, although I'm not sure these workarounds would do any good in your case.
回答3:
Thank you for your answers guys.
It was not OCSP after all. There happened to be some issues with certificates and some Apache configuration. We hired server guy and he fixed it.
So if anyone has this kind of problem should check Server configuration and look for ways to optimize it, also check for certificates. This fixed the 3-4 second of the waiting time on every response.
Bigger issue was use of geoplugin for detecting Country/City from IP address. I didn't know Curl could slow down response times that low. I'm not blaming geoplugin of course.
When I profiled my Code it said 127 Miliseconds from start till the end but turns out that profiler just skipped this geoplugin waiting time or smth.
In conclusion, modifying Code, dealing with certificates and server configuration made it happen.
P.S. I don't know how to deal with this bounty. I don't want it to go waste so I'm gonna give it to someone who answered even tho answer didn't resolve my issue and question was answered day before bounty was expiring and issue was already resolved.
来源：https://stackoverflow.com/questions/50803844/ssl-slow-establishing-secure-connection-taking-too-long