Thanks for providing feedback to us.

Could you provide net-internals logs for us to help the investigation. Instructions are available at https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details to help us investigate the issue. 

Are you using a self-signed cert, and clicking through Chrome's cert warning?  I've never heard of self-signed certs slowing things down that much, but if you're using them, we're not too concerned about performance of that use case.

Adding net-internals-log and screen shots.

We do use a self signed certificate on the website(Attaching screenshot of Browser warning/ error).

Deleted: net-internals-log.json 288 KB

net-internals-log.json 288 KB View Download

Deleted: net-internals-log.jpg 291 KB

	net-internals-log.jpg 291 KB View Download

Deleted: browser-warning.jpg 46.2 KB

	browser-warning.jpg 46.2 KB View Download

Does it mean that using a certificate with browser warnings on https connection causes the page load performance to slow down?

THis is an example URL: https://10.207.218.101:6002/login.html

The following openssl commands have been run to verify certificate chain and validity of the SSL certificate used for this HTTPS web application.
Avself.crt being SSL certificate and RootCA.crt being the Root certificate installed in browser's trusted list.

[root@airv_cu WebGUI]# cat Avself.crt RootCA.crt > ca_chain.crt
[root@airv_cu WebGUI]# openssl verify -CAfile ca_chain.crt Avself.crt
Avself.crt: OK
[root@airv_cu WebGUI]# openssl verify -CAfile ca_chain.crt RootCA.crt
RootCA.crt: OK

This looks to be a combination of self-signed cert-related perf issues (We mae a lot of extra connections through the self-signed cert codepath) and a slow HTTPS server.  It takes ~1 millisecond to make a connection, and then we send an SSL handshake, and it takes 220 milliseconds for the server to send its SSL handshake.  Then we send the second round of our handshake 1 millisecond later, and the server takes 673 milliseconds to respond with the second part of its handshake, for a total of about 893 millisecond waiting on the server, when establishing a connection.  When re-establishing a connection, the first round only takes 20 milliseconds, but the second round still takes 655 milliseconds.

So basically this is due to a combination of us making multiple connections (We make a connection, close it due to the cert error, and then make a new one, overriding that error), and a really slow SSL server.  I don't think we have an interest in using sockets more efficiently in the self-signed cert case, and this seems like it's mostly the server's fault.

I suspect the work to fix up the socket pool's interactions with cert click-throughs will end up fixing this as a side effect.

Running Chrome with following flag set through command line worked as workaround for this issue: chrome --ignore-certificate-errors

Which seems to completely remove the purpose of using SSL in the first place.  I really wouldn't recommend doing that.

So what can be the solution? Can Chrome community provide a patch/ fix for this issue? Any alternative suggestions?

I suggest not using self-signed certs, since they don't offer any protection if you don't have them registered with your local store (Which is the reason this issue falls under the "We really don't care much" category).  If you do have them registered with your store, you won't have this issue.  Also won't have to click through the cert warning every restart.

As suggested by david ben can this be a solution for this issue in the future versions of chrome:

Fix up the socket pool's interactions with cert click-throughs.

Except we don't care about perf in this case, so it's not worth developer time (Though it may inadvertently be fixed by refactors motivated by other behavior that is considered a bug, as davidben mentioned).

Anyhow, marking this WontFix.

This is not the case only with self-signed certificates. I replaced the self-signed certificate with a certificate signed by a trusted authority and still I see the page load is slow over HTTPS only on chrome.

What software is the server running? Also could you attach a new net-internals log of this happening against the server?

The Server is Running Goahead Webserver Software.
Attaching net-internals log

Deleted: net-internals-log.json 628 KB

net-internals-log.json 628 KB View Download

Please respond. This seems to be valid bug but is marked as WontFix.

Your net-internals log shows that you still have a certificate error. It's giving back ERR_CERT_COMMON_NAME_INVALID. If you needed to click through anything, you'll hit the slow path.

That said, slow path or not, that your server is having problems with a modest number of connections suggests you should talk to your server vendor. A small handful of connections should not take down an HTTP server.

Replaced with valid SSL certificate with no browser warnings and click-throughs, but still the load time is extremely huge than before or page becomes unresponsive.

Adding net-internals and Certificate validity message.

Deleted: net-internals-log-valid-ssl-1.json 339 KB

net-internals-log-valid-ssl-1.json 339 KB View Download

Deleted: Cert msg.jpg 49.8 KB

	Cert msg.jpg 49.8 KB View Download

The log is showing that your server software is slow. Please file a bug with your server software vendor.

In event 36338, I see it took us 3 seconds to establish a TCP connection with your server. I also see it took the server 14 seconds to respond to some data. Per event 36359, that was the HTTP request it couldn't respond to.

In event 36344, I see it took the server nearly 9 seconds to respond to the ClientHello.

In event 36367, I see it again took 14 seconds to respond to some data. That corresponds to event 36349, where it was the HTTP request it couldn't respond it.

In event 36372, I see it took the server 14 seconds to respond to the ClientHello.

(I see your server is also negotiating TLS 1.0 with TLS_RSA_WITH_AES_128_CBC_SHA. This is not a very good configuration, but this is unlikely to be the cause of your performance problems. You should be negotiating TLS 1.2 with an ECDHE-based AES-GCM cipher suite.)

But this issue is seen only in chrome. Other browsers work fine with the server software.

Any update on this ?

Apologies, I thought I'd responded but forgot to hit the button.

Returning to the triage queue just in case, but it's very likely this is a server bug.

The log is showing that the server is failing to respond when it is its turn to respond.

Sometimes servers have bugs which are tickled by certain patterns of socket use. For instance, the Python BaseHTTPServer can't service more than one socket at a time, which means any preconnect will cause the server to globally hang. Notably, I see that sockets 36337 and 36344 hang until about the same time (9200-ish) when socket 36338 decides to start a handshake after having done a TCP connection (sometimes we preconnect sockets and such).

Another possibility is we have some bizarre bug causing the entire I/O to lock up during some time windows. But then more than just that site would be slow. Chrome would be basically unresponsive. To distinguish those:

1. What happens if you try connecting to the server in another browser while it is being slow in Chrome?

2. When the server is being slow, do other sides work in Chrome?

3. Could you record an about:tracing log per these instructions?
https://www.chromium.org/developers/how-tos/submitting-a-performance-bug

Thank you for providing more feedback. Adding requester "zhongyi@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

1. When connecting to the server in another browser while it is being slow in Chrome the server doesn't respond to the other browser as well until it has served it in chrome. Please find tracing log attached.

2. I didn't get what you meant by: when the server is being slow, do other sides work in Chrome?. If you meant other sites, then other sites load as usual.

Deleted: trace_Page-Load1.json.gz 11.1 MB

trace_Page-Load1.json.gz 11.1 MB Download

Alright, that's conclusive then. #1 confirms the server is locked up and #2 confirms Chrome is not.

Please file a bug with your server vendor. Whatever Chrome is doing, if connecting to it causes the server to locked out other clients, that is definitively a server bug. It's probably blocking on the client sending something somewhere. That you're only seeing it in Chrome is probably some quirk of our socket pooling, but the server should be resilient to this. (Imagine if opening a connection to your favorite site were enough to knock if offline for everyone. That would be clearly unreasonable.)