parallel XmlHttpRequests

[Assaf Lavie]

I'm trying to run multiple xmlhttprequests in parallel in response to a
button click.
I want to launch N asynchronous requests and handle the responses as
they come. The problem is that no request is actually transmitted until
the previous one finishes, as though the browser limits the number of
actual connections to 1 and puts my requests in a queue. I tried this
on FF and IE.
Here's the code:

function newReq() {
if (window.XMLHttpRequest)
return new XMLHttpRequest();
else
return new ActiveXObject("Microsoft.XMLHTTP");
}

function Query(url) {
var req = newReq();
var url = url;
this.onres = function () {
if (req.readyState != 4) return ;
document.getElementById('results').innerHTML =
document.getElementById('results').innerHTML + "one more
response<br>";
}

this.go = function go() {
req.open("GET", url, true);
req.onreadystatechange = this.onres;
req.send(null);
}
}

d = new Query("foo1");
d.go();
e = new Query("foo2");
e.go();
f = new Query("foo3");
f.go();
g = new Query("foo4");
g.go();

[pcx99]

Assaf Lavie wrote:

I'm trying to run multiple xmlhttprequests in parallel in response to a
button click.
I want to launch N asynchronous requests and handle the responses as
they come. The problem is that no request is actually transmitted until
the previous one finishes, as though the browser limits the number of
actual connections to 1 and puts my requests in a queue. I tried this
on FF and IE.

This is a limit to the HTTP 1.1 protocol which is in place to prevent
the browser from flooding a server and to protect the net a little
against hackers and other bad guys. The reasons for the limit didn't
stand the test of time, they're not important today so much but the
browsers still respect the limits because they're part of the protocol
specifications.

You can get around this by modifying the client to handle more than 2
requests ( http://www.ajaxperformance.com/?p=33 ), but this is practical
only for intra-nets, another option is to use the Opera browser which
seem to ignore the limits. Again, only practical for intranets.
You can find a very good technical overview of the problem here:
http://www.oreillynet.com/xml/blog/2...about_xhr.html

Sorry, but there's no good answer for the question you have.

--
http://www.hunlock.com -- Musings in Javascript, CSS.
$FA

[Jim Land]

"Assaf Lavie" <as********@gmail.comwrote in news:1167325992.976614.16400@
73g2000cwn.googlegroups.com:

I'm trying to run multiple xmlhttprequests in parallel in response to a
button click.
I want to launch N asynchronous requests and handle the responses as
they come.

http://www.hunlock.com/blogs/Concurrent_Ajax

[Matt Kruse]

pcx99 wrote:

You can get around this by modifying the client to handle more than 2
requests ( http://www.ajaxperformance.com/?p=33 ), but this is
practical only for intra-nets

Why is it practical only for intranets? You mean, you can't control every
user's settings? This is true.

But everyone should increase the limits in their browsers. It speeds up the
web :)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Michael Winter]

pcx99 wrote:

[snip]

This is a limit to the HTTP 1.1 protocol which is in place to prevent
the browser from flooding a server and to protect the net a little
against hackers and other bad guys.

The connection limits are present to prevent general congestion -- a
hacker out to cause problems isn't about to respect protocol
limitations. The Internet does have finite capacity and congestion is
still a real concern. Servers also have a limit to the number of
connections that can be effectively managed.

Getting Web developers to understand the HTTP specification should help.
Simple things like sending a Content-Length header with
dynamically-generated responses would be a start. This eliminates the
need to discard connections: every entity across a persistent connection
must have self-defined length (4.4, RFC 2616) otherwise the end of the
message needs to be indicated by closing the connection.

The reasons for the limit didn't stand the test of time, they're not
important today so much ...

On what basis do you draw that conclusion? Doubling the number of
connections, for instance, doesn't guarantee an increase in performance,
and can you state for certain what effect it would have on the Internet
as a whole if implemented on a large scale?

I can't answer that question, which is why I would steer clear of
recommending practice like that when it may be harmful.

but the browsers still respect the limits because they're part of the
protocol specifications.

Doubtful. There isn't a single "mainstream" browser that is even
conditionally compliant with RFC 2616, though the extent of the
violations differ from one to the next.

The connection limit is only a recommendation, not a requirement for
compliance -- though recommendations in Standards Track RFCs are made
with a lot of weight. I would prefer to think that this recommendation
is heeded because there is little real reason to do otherwise.

[snip]

Mike

[Ted Zlatanov]

On 28 Dec 2006, ne********@mattkruse.com wrote:

But everyone should increase the limits in their browsers. It speeds
up the web :)

To be precise, it speeds up the individual experience. It makes web
servers slower because they serve more parallel requests, so it hurts
other users.

Ted

[Assaf Lavie]

Well, first of all, it seems the browser's limit on my machine is 1
connection, not 2. I know this from sniffing, not from the settings. I
can see the 2nd request only goes out once the first one is done.
According to FF's settings the limit is higher than 2. I raised all the
"max" settings to like 10 but it doesn't seem to have any effect. Keep
alive is also enabled. Could it be IIS that's limiting me? (running
locally) Any other ideas?

Thanks,
Assaf

pcx99 wrote:

Assaf Lavie wrote:

I'm trying to run multiple xmlhttprequests in parallel in response to a
button click.
I want to launch N asynchronous requests and handle the responses as
they come. The problem is that no request is actually transmitted until
the previous one finishes, as though the browser limits the number of
actual connections to 1 and puts my requests in a queue. I tried this
on FF and IE.

This is a limit to the HTTP 1.1 protocol which is in place to prevent
the browser from flooding a server and to protect the net a little
against hackers and other bad guys. The reasons for the limit didn't
stand the test of time, they're not important today so much but the
browsers still respect the limits because they're part of the protocol
specifications.

You can get around this by modifying the client to handle more than 2
requests ( http://www.ajaxperformance.com/?p=33 ), but this is practical
only for intra-nets, another option is to use the Opera browser which
seem to ignore the limits. Again, only practical for intranets.
You can find a very good technical overview of the problem here:
http://www.oreillynet.com/xml/blog/2...about_xhr.html

Sorry, but there's no good answer for the question you have.

--
http://www.hunlock.com -- Musings in Javascript, CSS.
$FA

[Matt Kruse]

Ted Zlatanov wrote:

On 28 Dec 2006, ne********@mattkruse.com wrote:

>But everyone should increase the limits in their browsers. It speeds
up the web :)

To be precise, it speeds up the individual experience. It makes web
servers slower because they serve more parallel requests, so it hurts
other users.

That would be a very tough case to prove, or even provide evidence for!

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[www.gerardvignes.com]

If You can set the maximum number of connections with IIS. Be advised
that if you are running it on a workstation for development purposes,
IIS sets a very low limit on the number of concurrent connections. You
get a license warning if you try to exceed it. I use IIS5 on W2kWS to
test with 3 browsers at once, and I am constantly getting timeouts
waiting for connections. It can be a good test of how your web
application performs in the face of adversity. I don't have this
limitation with Apache on Windows.

You can test with Firefox and the FasterFox extension (which is very
popular). FasterFox allows you to up the number of concurrent
connections. [This is bad news for web servers] FasterFox also gives a
fine degree of control. Some sites will block you if you use FasterFox.
DnsStuff.com comes to mind...

My website can handle as many concurrent XmlHttpRequests as the
connection will allow. I tag outgoing requests and incoming responses
with an Id that allows me to match them up and do high-level caching on
the client. It works well and gives good performance. I no longer
support browsers that don't support Ajax.

Gerard Vignes
http://www.GerardVignes.com
Seattle, WA

[Matt Kruse]

www.gerardvignes.com wrote:

I no longer
support browsers that don't support Ajax.

That's too bad. Since IE6 uses ActiveX for Ajax, and I have all ActiveX
disabled for public sites, I don't get any Ajax functionality when I am
using IE6. On some sites, this means a blank page. Of course, I just leave
those sites :)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[zero0x]

i am sorry, but i won't help you, i just want to say "what a great
code!" really, it is very nice, using method with ajax, is really very
good idea.

thx for space ;]

Assaf Lavie napísal(a):
[...]

[Laurent Bugnion [MVP]]

Hi Matt,

Matt Kruse wrote:

www.gerardvignes.com wrote:

>I no longer
support browsers that don't support Ajax.

That's too bad. Since IE6 uses ActiveX for Ajax, and I have all ActiveX
disabled for public sites, I don't get any Ajax functionality when I am
using IE6. On some sites, this means a blank page. Of course, I just leave
those sites :)

Any reason you have for still using IE6?

Greetings,
Laurent
--
Laurent Bugnion [MVP ASP.NET]
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch

[Matt Kruse]

Laurent Bugnion [MVP] wrote:

Any reason you have for still using IE6?

Corporate standard.

When I can control my browser choice, I use FF ;)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Jim Ley]

On Tue, 02 Jan 2007 20:00:40 +0100, "Laurent Bugnion [MVP]"
<ga*********@bluewin.chwrote:

>Hi Matt,

Matt Kruse wrote:

>www.gerardvignes.com wrote:

>>I no longer
support browsers that don't support Ajax.

That's too bad. Since IE6 uses ActiveX for Ajax,

no it doesn't only certain flavours of it, and the least interesting
really as they're not as flexible as other forms.

>and I have all ActiveX
disabled for public sites, I don't get any Ajax functionality when I am
using IE6. On some sites, this means a blank page. Of course, I just leave
those sites :)

Any reason you have for still using IE6?

IE7 is a piece of crap? with a UI designed for a 5 year old?

Jim.

[Laurent Bugnion [MVP]]

Hi Jim,

Jim Ley wrote:

On Tue, 02 Jan 2007 20:00:40 +0100, "Laurent Bugnion [MVP]"
<ga*********@bluewin.chwrote:

>Any reason you have for still using IE6?

IE7 is a piece of crap? with a UI designed for a 5 year old?

Jim.

Compared to IE6, IE7 is much better. Maybe not the UI (though I really
don't like the IE6 UI), but the engines.

I still prefer Firefox, but IMHO there are no reasons to continue using
IE6 over IE7...

Laurent
--
Laurent Bugnion [MVP ASP.NET]
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch

[Jim Ley]

On Tue, 02 Jan 2007 20:25:55 +0100, "Laurent Bugnion [MVP]"
<ga*********@bluewin.chwrote:

>I still prefer Firefox, but IMHO there are no reasons to continue using
IE6 over IE7...

Except for the UI... the FireFox Ui is also rubbish, although that
would help if it understood how to take native controls, and follow
the UI settings in the window manager a little more.

Jim.

[beegee]

Jim Ley wrote:

On Tue, 02 Jan 2007 20:00:40 +0100, "Laurent Bugnion [MVP]"
<ga*********@bluewin.chwrote:

Matt Kruse wrote:
That's too bad. Since IE6 uses ActiveX for Ajax,

no it doesn't only certain flavours of it, and the least interesting
really as they're not as flexible as other forms.

Yes it does, unless you're talking about iframe refreshing which I is
not only a huge pain but also does not really fit most peoples
conception of AJAX. But, actually, I'm more perplexed by Matt's
disabling ActiveX. Why? Why would you continue to use IE6 and disable
the one feature that makes it worth using?

Bob

[Richard Cornford]

beegee wrote:
<snip>

... . But, actually, I'm more perplexed by Matt's disabling
ActiveX. Why? Why would you continue to use IE6 and disable
the one feature that makes it worth using?

You disable ActiveX for the Internet security zone because there is a
big difference between an ActiveX component being "marked safe for
scripting" and its actually being safe.

Richard.