I am seeing super strange behavior and I am absolutely stumped. If I
open up
two tabs in Google Chrome (34), and in the first refresh our application
(foo.ourapp.com), which makes an ajax requests (via jQuery) that takes
20 or
so seconds to complete. Then in the other new tab hit refresh on
(foo.ourapp.com), the second tab blocks waiting until the ajax request
on
the first tab finishes. Inspecting Chrome developer tools shows:
However, if I open up Firefox and load up (foo.ourapp.com) while the
long
running ajax request is firing in Chrome, it loads fine. Thus, I have
determined that the client (Chrome) is blocking requests client-side.
However, according to http://www.browserscope.org/?category=network it
says
Chrome supports 6 connections per hostname, which should be fine, as I
am
only making two requests.
Any ideas on this? Pretty standard nginx config, with the following
notable
exceptions:
Even after disabling SPDY and restarting nginx, still seeing the same
behavior with requests blocking if another single request is outstanding
in
another tab.
On Fri, Apr 11, 2014 at 12:45:17PM -0400, justink101 wrote:
running ajax request is firing in Chrome, it loads fine. Thus, I have
add_header Strict-Transport-Security max-age=31556926;
add_header X-XSS-Protection “1; mode=block”;
add_header Access-Control-Allow-Origin $scheme://$account.myapp.com;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
Running nginx/1.5.12 with SPDY 3.1.
The “6 connections per hostname” is for normal http, not spdy - as
spdy specification requires no more than 1 connection per server
(as spdy allows to multiplex multiple requests within a single
connection). An obvious thing to check is if the problem goes
away if you switch off spdy.
Even after disabling SPDY and restarting nginx, still seeing the same
behavior with requests blocking if another single request is outstanding in
another tab.
Are you using php by any chance? I had a problem showing these exact
same
symptoms last week. By default, php writes to files for sessions. When
a
session is started, the file is locked by the current process and is
only
released at the end of the request or if session_write_close() is
called.
This will cause any requests in the same session to hang until the
first
completes. The process in this instance that is blocking is php and not
nginx.
We got around this by storing the session in Redis instead of files.
Yes using PHP. Could we simply just call session_write_close()
immediately
after we open and verify the session details? I’d like to avoid adding
another piece of infrastructure (redis) on every web server.
Lee we switched to using memcached for sessions and this helped, but
still
seeing blocking, though less time.
If we open two tabs, in the first page fire an ajax request that takes
20+
seconds to run, then in the second tab refresh, the page blocks loading
in
the second tab, but now instead of waiting the entire 20+ seconds for
the
first tab (ajax request) to finish, it only blocks around 8 seconds. See
screenshot: