Comments on: Digg shows Multipart XMLHttpRequest prototype

By: vegitto

vegitto — Thu, 04 Jun 2009 10:52:54 +0000

Interesting results people are getting.

I just tested in Chrome 2.x and found that the MXHR technique was much faster (for both the plain text and images demos).

Here are my differences:

MXHR Stream
Stream took: 384ms

Normal
Normal took: 5002ms

MXHR Stream
Stream took: 1549ms

Normal
Normal, uncached took: 10031ms

By: cates

cates — Fri, 29 May 2009 17:30:25 +0000

I see a real life example. How about a site like youtube with a lot of video thumbnails that need to be loaded? instead of 30+ thumbnails being laoded, just 1 request can be made

data url support in ie:
http://www.phpied.com/mhtml-when-you-need-data-uris-in-ie7-and-under/

By: stephaneeybert

stephaneeybert — Mon, 25 May 2009 07:59:21 +0000

Normal was twice faster on every request, even the first one.

Using Firefox 3.0.2 on Windows in a corporate environment.

By: AdrenalinMd

AdrenalinMd — Sat, 23 May 2009 20:10:56 +0000

You guys are funny, for “responders” you use yourself php (http://demos.digg.com/stream/testImageData.php) but into repository you have put only “Python, Ruby, Perl and Java” http://github.com/digg/stream/tree/9010257b1a6e1c236374d5205f0cee108a32256a/examples ;o)

By: AdrenalinMd

AdrenalinMd — Sat, 23 May 2009 20:05:09 +0000

Shouldn’t HTTP 1.1′s “persistent connections” handle this itself ? http://en.wikipedia.org/wiki/HTTP_persistent_connections
Also to prepare the batched answer on the server a php script(http://demos.digg.com/stream/testImageData.php) is used. So on server-side this technique is also not straightforward and can create additional probs..
Anyway it’s something interesting, on my internet mobile connections with firefox 2connections per server, with imageDemo I got “Stream took: 9461ms” “Normal, uncached took: 89240ms” almost 9.5x faster, not bad.

By: kilburn

kilburn — Fri, 22 May 2009 07:46:07 +0000

Yeah, the demo image shows a difference in favor of MXHR, but what about caching? Specifically: how do you tell the browser to cache the images received through the DUI.Stream?

Without this kind of caching, the technique limits itself to very large sets of unique assets that you’ll never need to load again. Maybe digg has a use for it, but I think the vast majority of us don’t…

By: vitalic

vitalic — Thu, 21 May 2009 21:40:33 +0000

Is it just me or is the timer not really accurate. If you look at the actual requests in the Firebug console the one MXHR request takes about 300ms compared to about 900ms for all ten individual requests, this seems to reflect the advantage better.

I think it sounds like a good idea and will definitely see if it can be used on the project I’m currently involved in.

P.S – what’s with the nazi registration process for this site, oh you want my phone number do you? Perhaps I should also set up a web cam and give you a url for a 24/7 live feed. Oh and that CAPTCHA looks secure.

By: hdragomir

hdragomir — Thu, 21 May 2009 20:32:04 +0000

I just had a look at the code, and it’s very well written. I’m sure you had a look yourselves, right?

Also, the image demo shows a difference in favor of MXHR, not the one linked to in the article.

By: mdmadph

mdmadph — Thu, 21 May 2009 19:19:14 +0000

Sounds a lot like Ext.Direct.

By: WillPeavy

WillPeavy — Thu, 21 May 2009 15:57:32 +0000

When I viewed the text demo (Chrome 2), MXHR took about 2.5x longer. For the 300 images demo, MXHR was about 15x faster.

By: willbo

willbo — Thu, 21 May 2009 15:16:03 +0000

We’ve been doing this to deliver CSS and JS files to the browser for a while, and grouping images into large sprites and using CSS to shuffle them around as background images, so I’m not really sure where the application for this comes in.

I’m almost never going to want to request a ton of images together via AJAX when I can use a sprite, and any blocks of text will be requested together anyway. Not to mention IE is funny about data URLs…

By: temsa

temsa — Thu, 21 May 2009 14:35:12 +0000

Well, any real difference with DWR’s call batches ? You do multiple requests at one time, then receive the multipart response and call the different callbacks associated to each part of the response.

This is fine, but far from new, and batches aren’t that easy to use because you have too know what has to be called and this is most of the time difficult to be determined dynamically.

By: hymanroth

hymanroth — Thu, 21 May 2009 14:14:40 +0000

This technique really comes into its own when the client cannot know beforehand what the response will contain, and hence could never request the components individually.

We’ve been using it for several years and are very happy with it.

By: russh

russh — Thu, 21 May 2009 13:49:44 +0000

The text example isn’t really taking advantage of this approach.

Here is a much better demo with image assets:
http://demos.digg.com/stream/imageDemo.html

However, as Jaaap says, not sure how you’d get around IE’s lack of data URL support…

By: Jaaap

Jaaap — Thu, 21 May 2009 13:36:10 +0000

How are you gonna display an image you received over XHR in the page? data uri’s dont work in IE7-

By: jeromew

jeromew — Thu, 21 May 2009 13:13:00 +0000

It’s a shame the demo really isn’t suited to showing off this idea, in that the implementation bears no resemblance to the situations they describe in the write up. It sounds very cool.

By: rasmusfl0e

rasmusfl0e — Thu, 21 May 2009 13:09:33 +0000

It’s a very clever idea indeed – but sadly the demo doesn’t do much to support it.

I’m guessing that in a real world scenario there might actually be great benefits to reap.

By: nicksergeant

nicksergeant — Thu, 21 May 2009 13:01:33 +0000

I had similar results as bogphanny. In almost every refresh in both Safari / Mac and FF3 / Mac, the normal approach is faster. Every once in a while, the MXHR request would be a *little* faster.

By: bogphanny

bogphanny — Thu, 21 May 2009 12:47:29 +0000

hmmm… had 3 shots of the demo, all showing the normal approach is much faster.

Stream took: 1348ms
Normal took: 620ms

Stream took: 1230ms
Normal took: 130ms

Stream took: 1519ms
Normal took: 140ms

* testing on FF 3.5b4 (OS X)