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.

We are trying to deploy Google Chrome across our corporate network, but we're finding that it takes 2-4X longer to load an https page (particularly our own internal ones) compared to IE. Has anyone experienced this and found a fix?

Update

Based on Handyman5's suggestion, I ran some diagnostics in Chrome, and found that the largest amount of time (over 90% on each page) was being spent on pulling static files from Cache and rendering the page. However, if I turn off SSL on our site, this is almost instantaneous.

Any thoughts on why this would be?

share|improve this question
    
Can you add a tcpdump trace? That would really help. Are you running out IPV6 in your network? I occasionally come across this issue where the sysadmin adds DNS records but doesn't enable V6 on the remote end point –  Lmwangi Jun 6 '11 at 6:55
    
We are not running IPV6, and I don't think DNS records are applicable since we're accessing the site directly (i.e. https:// 192.168.0.33/). I'll try to install wireshark or similar tool on a desktop to see if I can post a trace. –  Beep beep Jun 6 '11 at 7:15
    
what DNS servers do you use/ –  warren Jun 28 '11 at 19:06
    
Doesn't seem to matter ... internal DNS, Verizon, or even when accessing the site by IP address. –  Beep beep Jun 28 '11 at 19:43

6 Answers 6

Chrome has an awesome built-in diagnostic tool, "about:net-internals", which is designed to help troubleshoot network problems. In particular, it has an "Events" tab which lets you specify a URL and then Chrome breaks down the entire process of loading it, step-by-step, including DNS resolution, cache hits, and AJAX element requests.

share|improve this answer
    
Wow, never knew about this. I'll try it out, thanks! –  Beep beep Jun 29 '11 at 22:56
    
Weird ... I wonder if Chrome handles caching on secure sites differently than IE? After running this and the Timeline in Chrome's developer's tools, it appears that the longest time is being spent processing static files from Cache. On a non-secure site, this isn't the case - it pulls the cache files almost instantaneously. For example, on one small page, it took 100ms to receive the dynamic content from the page, but then another 1.9 seconds to pull javascript from cache. In IE, this page opens up in less than .5 seconds, and when I turn off SSL it opens up even faster in Chrome. –  Beep beep Jul 1 '11 at 11:03

tl;dr Check how Chrome handles certificate checking and revocation.

We had a very similar issue at a facility I previously worked at, but with Firefox. For this to be an issue, you need to confirm the issue is only with https pages. If not, it will make little difference.

With Firefox (I know, I know, I can read, point forthcoming), a bunch of people had issues while Internet Explorer users (if you can believe it) did not. We had used the infamous ipsCA authority because they were free for educational institutions, but eventually pissed off Firefox with their shadiness and OCSP checking of their certs was the culprit. Turns out the browser was delaying because of processing Certificate Revocation Lists because of the nature of our SSL certs. You obviously, as the best of us, did not mention your Chrome version, so it hard to say if it was an issue or is still an issue. However, I would check CRL configuration in Chrome. Doing so in Firefox alleviated out issue. Also, check your certs are in good-standing, that is if they are self-signed. What gave it away to use is we moved away from self-signed because idiot users of our services whined a lot and it was free. We thought we were saving ourselves a headache, but we made it worse.

share|improve this answer
    
Good thought - our internal apps are still in development and self-signed, so maybe that is the issue. We'll be buying a real cert, maybe that will make a difference. –  Beep beep Jun 6 '11 at 16:47
    
Well, disregard then. This issue would be with signed certs from a real CA, but the CA turns out to be crappy one. This is probably not your issue then. –  ajstein Jun 7 '11 at 7:28
    
We'll still try it out, I appreciate the feedback –  Beep beep Jun 7 '11 at 21:09

We deployed Google Chrome internally, to support a custom developed application (on ASP.NET MVC) but running on normal HTTP.

We also had issues with slow pages because of the cache. It seems Chrome was pulling all the static files on every page load, and not saving them in its cache. We ended up simply adding expires headers to our app to force the cache on, and that worked.

You could go down that route (modify your web applications to specify caching strategy for each type of file), or investigate further Chrome's default caching behavior.

Others seem to have similar problems (e.g. http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en).

This article may be useful as it provides a primer on Chrome caching: http://gent.ilcore.com/2011/02/chromes-10-caches.html

share|improve this answer
    
Our issue isn't that the files are being re-transmitted, but rather that pulling from cached files (in client-side memory) is really slow. I guess we'll have our internal users utilize IE. –  Beep beep Jul 2 '11 at 16:07
up vote 1 down vote accepted

In the end, I couldn't find an answer here. All the monitoring and profiling tests show that Google Chrome is very slow at loading secure static content from local client cache. No idea why. We had to have all of our internal users switch to IE (which is what most of the people with similar problems on the web did).

share|improve this answer

If the backend is java-based appserver, there is a common java bug that causes TLS Session Tickets to cause a huge delay. You can simulate the bug by using a really new openssl s_client and telling it to enable/disable session tickets.

The real culprit is JSSE vs. TLS extensions with null values, which session tickets use on the first request.

share|improve this answer
    
The back-end is ASP.NET MVC. –  Beep beep Jul 3 '11 at 22:17

Any possibility that your server runs out of random data. Under Linux if you use /dev/random and run out of random data your server will block and the page load will look like it hangs.

Usually /dev/urandom is good enough. If that is not the case there's some hardware you can get that will generate random data for you.

I see you are running ASP .NET -- I can't comment on wether that is an issue on Windows, but well worth a look.

share|improve this answer
    
Don't think so, since it's only in Chrome (and to an extent in Firefox). Our site is blazingly fast in IE, or in any browser if HTTPS is off. It appears to be related to pulling data from client-side cache. Chrome does so VERY slowly for an HTTPS site, but quickly for anon-https. Makes no sense to me. –  Beep beep Jul 5 '11 at 2:35

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.