I installed nginx 1.05 and php-fpm 5.3.10 in Ubuntu 11.10.
If I browse with explorer,firefox and chrome all works very well, all is
fast!
If I use my Playbook (with webkit) all is slow! With webinspector I
noticed that the problem is latency. I get a very high latency (from 3
to 15 seconds random) for all the pages with php code.
With the same playbook, I browse the SAME SITES inside other server
(actually I’ve just copied it in it ):
- nginx 0.84
- php 5.3.0
- ubuntu 9.10
and works very well and fast! It’s incredible!
I have attached the main nginx.conf, nginx-vs.conf, main php-fpm.conf,
php-fpm-vs.conf and fastcgi_params_phpfpm.
----- Messaggio originale -----
Da: “Maxim D.” [email protected]
A: [email protected]
Inviato: Venerdì, 2 marzo 2012 14:51:46
Oggetto: Re: Latency problem with one browser
Hello!
On Fri, Mar 02, 2012 at 05:15:54PM +0400, Max wrote:
If I browse with explorer,firefox and chrome all works very well, all is
- php 5.3.0
Hi,
With the same playbook, I browse the SAME SITES inside other server
keepalive_disable safari;
No. The problem is that keepalive is disabled by default for safari,
and the “keepalive_disable msie6;” will re-enable it.
Just for the record - keepalive_disable is set to msie6 and safari
by default, but using the keepalive_disable directive explicitly
disables keepalive for the specified arguments and implicitly
enables (by not disabling) keepalive for all the other possible
arguments.
So to enable keepalive for a browser that has keepalive disabled
by default (which currently includes msie6 and safari) you have
to use “keepalive_disable ID;”, where ID is anything but the ID
of the browser you want to enable keepalive for.
This disables keepalive for msie6 and implicitly enables
keepalive for safari and all the other browsers:
keepalive_disable msie6;
This disables keepalive for safari and implicitly enables
keepalive for msie6 and all the other browsers:
keepalive_disable safari;
This disables keepalive for safari and browser “none”,
and implicitly enables keepalive for msie6, but not
due to the “none” argument:
keepalive_disable none safari;
That’s because “none” does not actually reset the keepalive_disable
variable to zero, it’s implemented as another browser (2nd bit in the
keepalive_disable browser bitmap), so specifying “none” as a single
argument disables keepalive only for browser “none” and implicitly
enables it for all the other browsers.
I know this directive is a workaround in the first place, but it would
be nice if this were documented in the official documentation.
Maxim, do you think the Playbook browser should be added as a
separate browser (unsigned playbook:1 entry in ngx_http_headers_in_t)
to prevent it from getting the Safari keepalive disabled treatment?
Here’s a typical Playbook browser User-Agent string, adding an if
block for “Playbook” before the “Safari” if block in
ngx_http_process_user_agent() should do the trick:
Mozilla/5.0 (PlayBook; U; RIM Tablet OS 1.0.0; en-US)
AppleWebKit/534.8+ (KHTML like Gecko) version/0.0.1 Safari/534.8+
On Fri, Mar 02, 2012 at 08:48:43PM +0400, Max wrote:
Here’s a typical Playbook browser User-Agent string, adding an if
block for “Playbook” before the “Safari” if block in
ngx_http_process_user_agent() should do the trick:
Mozilla/5.0 (PlayBook; U; RIM Tablet OS 1.0.0; en-US)
AppleWebKit/534.8+ (KHTML like Gecko) version/0.0.1 Safari/534.8+
Detecting all browsers (thousands of them) which pretend to be
Safari is not an option. And, after all, browsers use other’s
product token for reason, and workarounds for bugs is what they
expect to get as a result.
I’m planning to disable this Safari workaround by default instead,
the following patch is already sitting in my queue:
The bug in question is likely already fixed (though unfortunately we
have
no information available as Apple’s bugtracker isn’t open), and the
workaround seems to be too pessimistic for modern versions of Safari
as well as other webkit-based browsers pretending to be Safari.
Mozilla/5.0 (PlayBook; U; RIM Tablet OS 1.0.0; en-US)
AppleWebKit/534.8+ (KHTML like Gecko) version/0.0.1 Safari/534.8+
Detecting all browsers (thousands of them) which pretend to be
Safari is not an option. And, after all, browsers use other’s
product token for reason, and workarounds for bugs is what they
expect to get as a result.
Except that PlayBook isn’t a browser, it’s a device
The bug in question is likely already fixed (though unfortunately we have
(NGX_CONF_BITMASK_SET
I don’t really agree with this, it’s analogues to removing IE
work-around
instead of restricting it to versions older than IE6 SV1. I was looking
at
this issue over the weekend and the “keepalive_disable safari” option is
simply too broad and that’s what needs to be fixed.
According to 5760 – Safari hangs when uploading files to certain php scripts,
the underlying issue was in the Foundation framework on iOS/OSX, not
Safari,
which means that Safari on Windows as well as everything else (Android,
BlackBerry, etc.) that uses WebKit was never affected.
I agree with you and I believe that it’s fixed in the most recent
releases
of iOS/OSX, but I wouldn’t bet that it’s fixed in iOS 4.x, OSX 10.6.x or
older releases, so why should we disable the work-around for them?
On Sun, Mar 04, 2012 at 02:39:53PM +0100, Piotr S. wrote:
Except that PlayBook isn’t a browser, it’s a device
prev->keepalive_disable,
this issue over the weekend and the “keepalive_disable safari” option is
simply too broad and that’s what needs to be fixed.
According to 5760 – Safari hangs when uploading files to certain php scripts,
the underlying issue was in the Foundation framework on iOS/OSX, not Safari,
which means that Safari on Windows as well as everything else (Android,
BlackBerry, etc.) that uses WebKit was never affected.
I agree with you and I believe that it’s fixed in the most recent releases
of iOS/OSX, but I wouldn’t bet that it’s fixed in iOS 4.x, OSX 10.6.x or
older releases, so why should we disable the work-around for them?
I believe that the workaround is too pessimistic even for affected
versions as it disables keepalive completely, while the problem
will only manifest itself if there are POSTs.
If someone will find itself affected and the cost of disabled
keepalive is acceptable - it will be still possible to explicitly
enable the workaround.
Restricting the workaround to something like “Safari on Mac OS X”
would be fine too, though it’s mostly orthogonal to changing the
default.
I believe that the workaround is too pessimistic even for affected
versions as it disables keepalive completely, while the problem
will only manifest itself if there are POSTs.
If someone will find itself affected and the cost of disabled
keepalive is acceptable - it will be still possible to explicitly
enable the workaround.
I’m aware of this and I still respectfully disagree with you, because
changing the default is basically trading correctness for performance.
Restricting the workaround to something like “Safari on Mac OS X”
would be fine too, though it’s mostly orthogonal to changing the
default.
Agreed, but it makes changing the default much less appealing.
