Kommentare zu: How better Caching helps Frankfurt’s Airport Website to handle additional load caused by the Volcano

Von: Andreas Grabner

Andreas Grabner — Thu, 09 Dec 2010 16:10:03 +0000

Hi Markus – yeah – it is interesting that there are still so many sites out there that do not follow those best practices. Can’t say that everything is easy to change – but most changes should be easy

Von: Markus Leptien

Markus Leptien — Thu, 09 Dec 2010 15:38:19 +0000

History repeating. Berlin Airport almost shut down due to snow. Webpage often not reachable due to overload. Closer look reveals:
1. No GZIP and no minification at all (Neither HTML/JS/CSS)
2. No Keep-alives
3. No Caching-Headers
4. Suspicious ETAG-Headers
5. More than 0,5 MBytes of weight, one image alone is more than 25% of it.
6. 4 blocking Javascripts right at the beginning of the page
7. No spriting

http://www.berlin-airport.de

Von: Bruce

Bruce — Wed, 19 May 2010 11:15:26 +0000

Great analysis Andreas, hope you made it safely back after we met in Linz I also had a hard time digging for information below the ash. Most airlines and airports were either down or not providing updates…

I am pretty sure that almost all sites that serve most of their content on their own could work with 1-2 seconds keep alive much better than without. Sure you leave the last 1 or 2 connections open for 2 seconds longer than you would have needed. But that should not be the limiting factor if the server is already serving content for 5 or more seconds.

if you do not serve content besides html, because you don’t have it, or its served off an cdn I would not turn it on

Von: Fabian

Fabian — Tue, 11 May 2010 20:38:57 +0000

if you do not serve content besides html, because you don’t have it, or its served off an cdn I would not turn it on

Von: christian boots

christian boots — Wed, 05 May 2010 03:29:31 +0000

I forgot to add that of course the caching-issue needs to be resolved first. This would greatly reduce the number of connections.

Von: Markus Leptien

Markus Leptien — Mon, 26 Apr 2010 14:36:28 +0000

@Thomas: Yes, sorry, the Blog-Software stripped the formatting. What that meant is that for example
Firefox 3 uses with HTTP 1.0 6 connections in parallel, and with HTTP 1.1 6 connections. IE 8 the same.
Safari 3 and 4 uses with HTTP 1.0 4 connections, and with HTTP 1.1 4 connections. Chrome the same.
So with the newer Browsers, switching protocols between HTTP 1.0 and HTTP 1.1 will not reduce the amount of concurrent connections.

Von: Thomas Falkenberg

Thomas Falkenberg — Mon, 26 Apr 2010 12:02:05 +0000

@Andreas: of course a CDN (or a cloud is the way to go for a high traffic, international website with a high volume on static elements. This usually doesn’t take pressure from the application server though, but from the webserver, but I guess that is what you meant.
I totally agree that bringing down the number of resources is the key here. My point is that you have to know and monitor your connections (consuming handles,RAM) BEFORE switching on keep-alive. Otherwise you risk a complete outage. I’ve seen exactly this case before, that’s why I wanted to mention.
@Markus:I was refering to a long-term trend, where newer browser versions gain a bigger market share. This will bring your total connections up in a non-linear manner, but I know what you meant.
I don’t understand the numbers, what do they represent?

Von: Markus Leptien

Markus Leptien — Thu, 22 Apr 2010 12:35:58 +0000

@Thomas:
Actually it is still linear, though steeper.

And there is a trade-off, you might have a higher amount of open connections, but less processing for(by a factor of ~40 in this case) TCP Handshakes and Tear-down, and the page loads faster, so the connection is open for a shorter time.

And as long as they used HTTP1.0 it was:
Browser HTTP/1.1 HTTP/1.0
IE 6,7 2 4
IE 8 6 6
Firefox 2 2 8
Firefox 3 6 6
Safari 3,4 4 4
Chrome 1,2 6 ?
Chrome 3 4 4

Von: Andreas Grabner

Andreas Grabner — Thu, 22 Apr 2010 12:02:32 +0000

@Thomas: all good points. I used IE7 in my example (i know – old browser – but unfortunately still a major player).
Modern browsers that use more physical connections by default allow faster parallel download – but – as you indicated correctly – open more connections to the server. For that reason you should follow the best practies of “merging files” (CSS, JavaScript, Images) or use a CDN (Content Delivery Network). A CDN serves mostly static content to the end-user from a location as close as possible to the end-user – thus – taking pressure of the application server (as only dynamic requests make it to the AppServer) and it also speeds up content delivery of static objects as CDN Servers are usually closer to the end-user than your appserver

Keep in mind. Not using Keep-alive means that you always pay the penality of re-establishing a connection FOR EVERY resource on the page. If you have >100 elements (like on this page) it means that you pay a high price on end-user performance.

The best way to deal with a situation like the one analyzed is really to bring down the number of resources – this solves most of the highlighted problems

makes sense?

Von: Thomas Falkenberg

Thomas Falkenberg — Thu, 22 Apr 2010 11:59:07 +0000

I forgot to add that of course the caching-issue needs to be resolved first. This would greatly reduce the number of connections.