Google Chrome: Good News for Comet
by Jose Maria ArranzSeptember 5th, 2008
Google Chrome was released this week.
After an initial review, it is very nice software. It gets a significant advantage by being based on Apple’s WebKit rendering engine, known for its quality, performance small footprint, and ease of development. WebKit’s inclusion in Chrome is not a surprise because it is already used in Android.
Chrome introduces two important improvements:
- Every web page runs in a different process.
- JavaScript is compiled behind the scenes using the Danish V8 engine.
Both are good news for Ajax and Comet , but the most important for me is the first one. Why?
A synchronous XMLHttpRequest request no longer hangs the browser, only the tab containing the locked web page is hung and can be closed. This is very important for applications with predictability as a strong requirement.
And there is more good news:
Chrome does not respect the HTTP 1.1 limit of two connections per domain!
I have tried to open five remote views (five tabs) using long polling with ItsNat and no problem for Chrome, browsing works as usual. The following picture shows this experiment:
The left tab is the source web page, other tabs are remote views listening for changes in the source using long-polling.
But the number of connections is not unlimited: a new remote view locks the source web page (closing a remote view unfreezes the source web page).
In summary, Google Chrome supports 6 simultaneous HTTP connections per domain.
Doing the same with other browsers, this is the maximum number of default remote views without the browser locking-up:
Safari 3.1: 3 remote views => 4 connections
Firefox 3.0: 5 remote views => 6 connections (Firefox v2 had 2 connections)
Opera 9.5: 7 remote views => 8 connections (with very much effort)
Internet Explorer 6 & 7: 1 remote view => 2 connections
Internet Explorer 6 and 7 hangs miserably when the connection limit is reached. Firefox 2 freezes the browser, but Firefox 3 recovers when closing a remote view. The same is true for Safari 3.1 and Opera 9.5, and of course Chrome. Internet Explorer 8 Beta and Firefox 3.1 Beta were not tested at this time.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
September 6th, 2008 at 12:31 pm
I’m curious to hear more about why its good to have synchronous XHR requests in a Comet application.
September 8th, 2008 at 1:14 am
Almost any Comet application based on long polling is an Ajax application. Of course I know long polling is essentially asynchronous.
One simple example: closing a Comet session/channel.
Imaging we have a Comet channel generating JavaScript code to add new data to a web page, this data is added in a concrete zone of the page. When the user does some concrete action the comet channel must be closed, furthermore, the web page itself changes with no page reload and the comet zone is lost.
Using a synchronous XHR request you can mandate to the server to finish sending any new data, after that the page is changed accordingly. If the XHR request is asynchronous the browser uses a different thread to communicate with the server so this request is non-blocking, the page may be changed before the notification arrives to the server, and accidentally a pending Comet event may arrive to the browser.
Of course this is not a serious problem because JavaScript errors are usually quietly ignored, but in ItsNat JavaScript errors can optionally be shown with an alert (by the way the current version has a bug just fixed in the upcoming release).
September 16th, 2008 at 4:08 pm
there are so many advantages and features with Chrome, such as it’s speed, for example; now if only they would take care it’s quirky cookie management…
October 16th, 2008 at 2:58 am
It seems that Google Chrome support for Comet is very limited. Only long polling works, while streaming does not work (here some information regarding long polling vs. streaming: http://meteorserver.org/interaction-modes/).
I posted an item to the Chromium issue list: http://code.google.com/p/chromium/issues/detail?id=2016
Until this is solved, it is not really good news for Comet.
November 18th, 2008 at 10:09 pm
ie connections can be changed. Thus IE7 can ignore the HTTP 1.1 limit of 2, see KB282402 or http://support.microsoft.com/kb/282402. I tried it, it really seems to speed things up. The question is should a large company, change its IE settings to 10 connections to improve performance of web apps?