Comments on: Performance Research, Part 4: Maximizing Parallel Downloads in the Carpool Lane http://yuiblog.com/blog/2007/04/11/performance-research-part-4/ News and Artilces about Designing and Developing with Yahoo! Libraries. Fri, 08 Aug 2008 01:11:41 +0000 http://wordpress.org/?v=2.3.3 By: To Speeding up Your Web Site « Sanantoniowebdesign Weblog http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-436911 To Speeding up Your Web Site « Sanantoniowebdesign Weblog Mon, 04 Aug 2008 05:44:06 +0000 http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-436911 [...] more information check “Maximizing Parallel Downloads in the Carpool Lane” by Tenni Theurer and Patty [...] […] more information check “Maximizing Parallel Downloads in the Carpool Lane” by Tenni Theurer and Patty […]

]]> By: Non-blocking JavaScript Downloads » Yahoo! User Interface Blog http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-426379 Non-blocking JavaScript Downloads » Yahoo! User Interface Blog Tue, 22 Jul 2008 18:42:01 +0000 http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-426379 [...] is two components per hostname. For more information of this topic check the article “Maximizing Parallel Downloads in the Carpool Lane” by Tenni [...] […] is two components per hostname. For more information of this topic check the article “Maximizing Parallel Downloads in the Carpool Lane” by Tenni […]

]]> By: Performance web » Archive du blog » Limitation du nombre de requêtes http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-343929 Performance web » Archive du blog » Limitation du nombre de requêtes Mon, 07 Apr 2008 15:57:36 +0000 http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-343929 [...] les téléchargements puisque les limites sont “par domaine”. Au delà de 4 domaines l’équipe de performance Yahoo! a remarqué qu’entre une trop grande parallélisation et la multiplication des requêtes DNS, [...] […] les téléchargements puisque les limites sont “par domaine”. Au delà de 4 domaines l’équipe de performance Yahoo! a remarqué qu’entre une trop grande parallélisation et la multiplication des requêtes DNS, […]

]]> By: Performance Research, Part 5: iPhone Cacheability - Making it Stick » Yahoo! User Interface Blog http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-299437 Performance Research, Part 5: iPhone Cacheability - Making it Stick » Yahoo! User Interface Blog Wed, 06 Feb 2008 20:24:02 +0000 http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-299437 [...] experiments conducted to learn more about optimizing web page performance (Part 1, Part 2, Part 3, Part 4). You may be wondering why you’re reading a performance article on the YUI Blog. It turns out [...] […] experiments conducted to learn more about optimizing web page performance (Part 1, Part 2, Part 3, Part 4). You may be wondering why you’re reading a performance article on the YUI Blog. It turns out […]

]]> By: Dieter_be http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-256171 Dieter_be Mon, 10 Dec 2007 20:00:44 +0000 http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-256171 Great series. Steve's talk for google was also very interesting. We have your book at the company and I think everyone should read it Great series. Steve’s talk for google was also very interesting. We have your book at the company and I think everyone should read it

]]> By: Jarmark.org » Rails 2.0 okiem zgreda http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-208939 Jarmark.org » Rails 2.0 okiem zgreda Thu, 11 Oct 2007 10:10:43 +0000 http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-208939 [...] urli do takich feedów. Ocena plus dodani: +1 Obsługa assetów Druga pozytywna grupa zmian. Doświadczenia przeprowadzone przez chłopaków z Yahoo dowodzą, że spore przyspieszenie ładowania aplikacji można uzyskać jeżeli dane (JS, CSS, [...] […] urli do takich feedów. Ocena plus dodani: +1 Obsługa assetów Druga pozytywna grupa zmian. Doświadczenia przeprowadzone przez chłopaków z Yahoo dowodzą, że spore przyspieszenie ładowania aplikacji można uzyskać jeżeli dane (JS, CSS, […]

]]> By: Dan Moore! » Interesting posts about web application performance http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-208758 Dan Moore! » Interesting posts about web application performance Wed, 10 Oct 2007 23:03:11 +0000 http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-208758 [...] The good folks over at the YUI blog posted this: What the 80/20 Rule Tells Us about Reducing HTTP Requests a while ago. I bookmarked it, but wanted to point it out to other folks–it’s a nice bit of research, with numbers and graphs and all that good stuff. It opened my eyes to various non intuitive aspects of web application performance. The whole series is a nice read; part 1 is linked above and here’s part 2, part 3 and part 4. [...] […] The good folks over at the YUI blog posted this: What the 80/20 Rule Tells Us about Reducing HTTP Requests a while ago. I bookmarked it, but wanted to point it out to other folks–it’s a nice bit of research, with numbers and graphs and all that good stuff. It opened my eyes to various non intuitive aspects of web application performance. The whole series is a nice read; part 1 is linked above and here’s part 2, part 3 and part 4. […]

]]> By: Ian http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-196094 Ian Fri, 21 Sep 2007 10:39:00 +0000 http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-196094 Aren't your figures, and your basic premise, failing to take into account that bandwidth is not unlimited? If I have one pipe which is fat or divide that into 20 pipes which are thin, download time will be the same (r.e. your Fig 3.) The difference is in how the HTTP requests are allocated. Initiating 20 HTTP connections requires much more overhead than one. You need to measure bandwidth for each connection to really see whether you have a saving; your analysis is flawed otherwise. Also, the transactional overhead of HTTP has to be taken into account (which is where the differences between pipelining and not occurs; or even parts of the difference for HTTP/1.0 vs. HTTP/1.1) Aren’t your figures, and your basic premise, failing to take into account that bandwidth is not unlimited?

If I have one pipe which is fat or divide that into 20 pipes which are thin, download time will be the same (r.e. your Fig 3.) The difference is in how the HTTP requests are allocated. Initiating 20 HTTP connections requires much more overhead than one.

You need to measure bandwidth for each connection to really see whether you have a saving; your analysis is flawed otherwise. Also, the transactional overhead of HTTP has to be taken into account (which is where the differences between pipelining and not occurs; or even parts of the difference for HTTP/1.0 vs. HTTP/1.1)

]]> By: » 14 hal untuk membuat website yang cepat diload TIRTA - Versi 2: http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-182647 » 14 hal untuk membuat website yang cepat diload TIRTA - Versi 2: Fri, 31 Aug 2007 19:02:55 +0000 http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-182647 [...] kenyataanya Java Script menghalangi browser melakukan parallel downloads dan menghalangi rendering semua content yang berada di bawahnya (CSS, HTML, image, dll). Pada [...] […] kenyataanya Java Script menghalangi browser melakukan parallel downloads dan menghalangi rendering semua content yang berada di bawahnya (CSS, HTML, image, dll). Pada […]

]]> By: Client side web site performance — onenaught.com http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-168128 Client side web site performance — onenaught.com Mon, 06 Aug 2007 08:04:41 +0000 http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#comment-168128 [...] Maximizing Parallel Downloads in the Carpool Lane [...] […] Maximizing Parallel Downloads in the Carpool Lane […]

]]>