0

Problem: When executing around 10 jQuery $.ajax requests at once, I can see all the requests in firebug in the (pending) state, however, it looks like the browser is only handling one request at a time. This causes the rest of the requests to timeout like it was one big request. Is there a way to resolve this, so that all of the async requests sent out at one time are handled in parallel? Thanks!

$.ajax({
        type: "GET",
        url: testScriptPHP,
        async: true,
        cache: false,
        timeout: 30000,
...
Fostah
  • 2,947
  • 4
  • 56
  • 78
  • Are there any other request being made? Usually a browser makes around 8 requests at a time iirc. – Ivan Aug 15 '12 at 22:27
  • 1
    I don't think you'll ever get 10 parallel requests, because browsers limit the # of concurrent connections per domain (see http://stackoverflow.com/questions/561046/how-many-concurrent-ajax-xmlhttprequest-requests-are-allowed-in-popular-browse). If that is important to your application, look into WebSockets (with Flash fallbacks for older browsers) so you can just keep 1 persistent connection open and send all requests using that. – Yoshi Aug 15 '12 at 22:31
  • @Yoshi Thanks that thread was very useful. I guess my only solution for now is to increase the timeout to a very high number so the requests will not timeout and it will use the maximum connections possible for the browser. If I could maintain one persistent connection I would, however, for this project I need to make independent calls for the data I need. – Fostah Aug 15 '12 at 22:52

2 Answers2

1

It's a classical issue of having the session blocking simultaneous requests.

The obvious solution - is to close session as soon as you don't need it using session_write_close()

zerkms
  • 249,484
  • 69
  • 436
  • 539
  • You're probably right. In fact this type of question has been asked before and the answer was the same: http://stackoverflow.com/a/4903453/450141 – Yoshi Aug 15 '12 at 22:35
  • @Yoshi: to be clear I've already answered such type of question at least 3 times here, just too lazy to find them ;-) – zerkms Aug 15 '12 at 22:40
  • 1
    @Yoshi: http://stackoverflow.com/a/11569627/251311 http://stackoverflow.com/a/4457200/251311 – zerkms Aug 15 '12 at 22:42
  • @zerkms The php script I am hitting does have a session_start() or any session data. It basically runs a shell_exec and returns a string and exits. Would I still need session_write_close()? – Fostah Aug 15 '12 at 22:44
  • @Fostah: if you don't want it to be locked - yes. And remember it is just a guess. It's highly likely it's caused by sessions, but the cause of locking can be somewhere else as well. – zerkms Aug 15 '12 at 22:46
  • @zerkms I meant to say, it does NOT have a session_start() or any session code in the PHP script I am hitting. Sorry about that. The webserver is lighthttpd on OE so it may be limiting the connections as well. From browserscope it looks like at least 2-6 should be firing off at a time. – Fostah Aug 15 '12 at 22:54
  • @Fostah: then - yes, it's likely locked by something else, sorry for bad guess – zerkms Aug 15 '12 at 23:04
  • @zerkms No worries, thanks for the consideration. I just checked firefox's about:config and saw pipelining was disabled by default which I believe is causing the issue. (http://en.wikipedia.org/wiki/HTTP_pipelining) – Fostah Aug 15 '12 at 23:06
0

Found the issue!

Turns out the lighttpd.conf had max workers commented out which was causing lighttpd to run with 1 worker!

I upped max workers to 30 and it's flying now!

Fostah
  • 2,947
  • 4
  • 56
  • 78