We’re seeing very long SSL negotiation times of 2-9 seconds that are blowing out results and are not reflective of real world results. It happens for services like Facebook and New Relic.
Is it just us or a wider problem?
Screenshot attached. Can send through specific test if required.
Try running the same test with Chrome to see if the delay is because of certificate revocation checks (they will show up as additional requests in the SSL negotiation time).
We had a bug that we fixed recently (few weeks ago) where the OS certificate caches were not getting cleared so IE was showing faster SSL times than Firefox and Chrome because of cached certificate results.
Real world results will be somewhere in between depending on the user’s operating system and how recently they have visited a site that establishes SSL connections to the given domain (Windows XP doesn’t do revocation checks but Windows 7 and later do).
Hi,
since we have migrated our private instance from Windows XP to Windows 7, we have exactly the same “problem”.
I can reproduce on my own pc when doing:
Here a screenshot:
[attachment=242]
Best regards,
Vincent
Hi,
I’m also facing similar issues. For my https pages, the SSL negotiation time taken is around 3 to 9 seconds which makes the total page load time between 12 - 20 seconds which is wrong.
When I test the same pages through other tools such as GTMetrix, gomez etc, the total page load time is well under 7 seconds.
Is this bug still open in the online version of WPT (http://www.webpagetest.org/)?
[attachment=247]
Syam
It’s not a bug, what you see is actually the result of a bug being fixed where webpagetest was not clearing the OS OCSP and CRL caches. The reason a lot of the other tools are not showing it is that they are not using IE on Windows Vista+ or if they are then they are also not clearing the certificate caches and the certificate verification is being cached across tests.
For private instances I may be able to provide a config setting that allows you to disable the certificate cache clearing but it is absolutely something you should pay attention to (it is actually a recent optimization that Cloudflare implemented - http://blog.cloudflare.com/ocsp-stapling-how-cloudflare-just-made-ssl-30 ).
It is a bit unfortunate that the OCSP/CRL requests are not displayed in the waterfall. If you capture a tcpdump then you can see them happening and the SSL negotiation is completely blocked until the additional requests complete. The IE 10 agent uses a different method for capturing the waterfall data and you can clearly see the certificate validation requests: http://www.webpagetest.org/result/130107_7D_48e1073a699d102c1dc1516fe9820fc7/1/details/
Having to do 6 certificate validations for your base page is what is making the negotiation time so long. If you look further down the waterfall you can see the omniture request has 1 validation check and the doubleclick negotiations each generate 2 CRL requests (which are more expensive than OCSP)
I was trying to check the speed difference in my site when loading jQuery from https or http of Google’s CDN that contains the jQuery library among others.
IE10:
http://www.webpagetest.org/result/130303_5Z_CX4/1/details/
1.4 seconds is a lot, when in my own PC, chrome dev tools shows the total time 140 ms (55 ms for SSL).
I tried resetting the SSL certs (win7) with the code the have put in this thread:
[code]certutil -urlcache * delete
Because googleapis is a popular CDN , it’s quite unrealistic that for someone will take as much as 1.4s
Chrome does not do OCSP or CRL checks which is why it is so much faster. IE does.
That said, I’m working on an update that will only clear the cert caches if explicitly requested. Should be available later today in the advanced settings.
Patrick, is it in current version possible to disable cache clearing? I have similar issue and it seems that it does not represent typical use case when users do not have cleared cerfificate caches.
Regards,
The current code shouldn’t be clearing the certificate caches. Are you seeing it on the public instance or a private instance? If it’s a private instance you might want to update the agent since I think the change was made after the 2.12 release.
Thanks!
Usually I upgrade agents and WPT Server to the newest version from the repository.
Since what version of the agent it behaves as described above? I am not sure how WPT server version corresponds to agent version.
The latest test agents are available from the prod server between official releases: https://sites.google.com/a/webpagetest.org/docs/private-instances#TOC-Updating-Test-Agents
Looks like the change was made back in March though so even a 2.12 release should not be clearing out the cert cache by default: Added support for emulating a mobile browser using Chrome (UA string,… · WPO-Foundation/webpagetest@fb0fc20 · GitHub (you can force it by passing clearcerts=1 on a test but by default it shouldn’t be clearing them).
Thanks, Patrick!