Latency problem with one browser

Hi,

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.

Any idea?

Thanks a lot,

Andrea

Hello!

On Fri, Mar 02, 2012 at 01:38:45PM +0100, Andrea S. wrote:

  - 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.

Any idea?

Try

keepalive_disable msie6;

http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_disable

Maxim D.

02 марта 2012, 17:09 от Maxim D. [email protected]:

http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_disable

This is WebKit related, so this is more likely to help:

keepalive_disable safari;

Max

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

keepalive_disable msie6;

http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_disable

This is WebKit related, so this is more likely to help:

keepalive_disable safari;

No. The problem is that keepalive is disabled by default for safari,
and the “keepalive_disable msie6;” will re-enable it.

Maxim D.

Yes,

with “keepalive_disable none;” works fine!

Thanks a lot,
Andrea

----- 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

keepalive_disable msie6;

http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_disable

This is WebKit related, so this is more likely to help:

keepalive_disable safari;

No. The problem is that keepalive is disabled by default for safari,
and the “keepalive_disable msie6;” will re-enable it.

Maxim D.


nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx

Hi,

This disables keepalive for safari and browser “none”,

I know this directive is a workaround in the first place, but it would
be nice if this were documented in the official documentation.

It is:
http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_disable

Best regards,
Piotr S. < [email protected] >

02 марта 2012, 17:52 от Maxim D. [email protected]:

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.

Max

02 марта 2012, 19:53 от Andrea S. [email protected]:

Yes,

with “keepalive_disable none;” works fine!

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+

Max

Hello!

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:

HG changeset patch

User Maxim D. [email protected]

Date 1330697796 -14400

Node ID 88e257b4bd3d61e30d1421ab6f2e417a8baedb96

Parent 277a1822fc5cf7ad83297c74839ca8c84a49680c

Removed safari from keepalive_disable default.

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.

diff --git a/src/http/ngx_http_core_module.c
b/src/http/ngx_http_core_module.c
— a/src/http/ngx_http_core_module.c
+++ b/src/http/ngx_http_core_module.c
@@ -3568,8 +3568,7 @@ ngx_http_core_merge_loc_conf(ngx_conf_t
ngx_conf_merge_bitmask_value(conf->keepalive_disable,
prev->keepalive_disable,
(NGX_CONF_BITMASK_SET

  •                           |NGX_HTTP_KEEPALIVE_DISABLE_MSIE6
    
  •                           |NGX_HTTP_KEEPALIVE_DISABLE_SAFARI));
    
  •                           |NGX_HTTP_KEEPALIVE_DISABLE_MSIE6));
    
    ngx_conf_merge_uint_value(conf->satisfy, prev->satisfy,
    NGX_HTTP_SATISFY_ALL);
    ngx_conf_merge_uint_value(conf->if_modified_since,
    prev->if_modified_since,

Maxim D.

Hi Maxim,

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 :wink:

The bug in question is likely already fixed (though unfortunately we have
(NGX_CONF_BITMASK_SET

  •                           |NGX_HTTP_KEEPALIVE_DISABLE_MSIE6
    
  •                           |NGX_HTTP_KEEPALIVE_DISABLE_SAFARI));
    
  •                           |NGX_HTTP_KEEPALIVE_DISABLE_MSIE6));
    
    ngx_conf_merge_uint_value(conf->satisfy, prev->satisfy,
    NGX_HTTP_SATISFY_ALL);
    ngx_conf_merge_uint_value(conf->if_modified_since, prev->if_modified_since,

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 https://bugs.webkit.org/show_bug.cgi?id=5760#c38,
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?

Best regards,
Piotr S. < [email protected] >

Hello!

On Sun, Mar 04, 2012 at 02:39:53PM +0100, Piotr S. wrote:

Except that PlayBook isn’t a browser, it’s a device :wink:

                          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 https://bugs.webkit.org/show_bug.cgi?id=5760#c38,
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.

Maxim D.

Hi Maxim,

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.

Best regards,
Piotr S. < [email protected] >

Hello!

On Sun, Mar 04, 2012 at 10:08:45PM +0100, Piotr S. wrote:

  • Mozilla/5.0 (iPad; CPU OS 5_0_1 like Mac OS X) …
  •            r->headers_in.safari_osx = 1;
    
  •        }
    

I would rather do

— a/src/http/ngx_http_request.c
+++ b/src/http/ngx_http_request.c
@@ -1493,7 +1493,9 @@ ngx_http_process_user_agent(ngx_http_req
} else if (ngx_strstrn(user_agent, “Chrome/”, 7 - 1)) {
r->headers_in.chrome = 1;

  •    } else if (ngx_strstrn(user_agent, "Safari/", 7 - 1)) {
    
  •    } else if (ngx_strstrn(user_agent, "Safari/", 7 - 1)
    
  •               && ngx_strstrn(user_agent, "Mac OS X", 8 - 1))
    
  •    {
           r->headers_in.safari = 1;
    
       } else if (ngx_strstrn(user_agent, "Konqueror", 9 - 1)) {
    

As the sole purpose of r->headers_in.safari bit is to activate
this particular workaround. Any objections?

Maxim D.

Hi Maxim,

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 this patch is sufficient.

“Mac OS X” string is present in all affected devices, i.e.:

  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8) …
  • Mozilla/5.0 (iPad; CPU OS 5_0_1 like Mac OS X) …
  • Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) …
  • Mozilla/5.0 (iPod; CPU iPhone OS 5_0_1 like Mac OS X) …

— src/http/ngx_http_request.c.orig Sun Mar 4 20:53:14 2012
+++ src/http/ngx_http_request.c Sun Mar 4 20:55:36 2012
@@ -1496,6 +1496,10 @@ ngx_http_process_user_agent(ngx_http_request_t
*r, ngx
} else if (ngx_strstrn(user_agent, “Safari/”, 7 - 1)) {
r->headers_in.safari = 1;

  •        if (ngx_strstrn(user_agent, "Mac OS X", 8 - 1)) {
    
  •            r->headers_in.safari_osx = 1;
    
  •        }
    
  •    } else if (ngx_strstrn(user_agent, "Konqueror", 9 - 1)) {
           r->headers_in.konqueror = 1;
       }
    

— src/http/ngx_http_request.h.orig Sun Mar 4 20:55:38 2012
+++ src/http/ngx_http_request.h Sun Mar 4 20:56:04 2012
@@ -228,6 +228,7 @@ typedef struct {
unsigned gecko:1;
unsigned chrome:1;
unsigned safari:1;

  • unsigned safari_osx:1;
    unsigned konqueror:1;
    } ngx_http_headers_in_t;

— src/http/ngx_http_core_module.c.orig Sun Mar 4 20:56:25 2012
+++ src/http/ngx_http_core_module.c Sun Mar 4 20:56:42 2012
@@ -1485,7 +1485,7 @@ ngx_http_update_location_config(ngx_http_request_t
*r)
*/
r->keepalive = 0;

  •    } else if (r->headers_in.safari
    
  •    } else if (r->headers_in.safari_osx
                  && (clcf->keepalive_disable
                      & NGX_HTTP_KEEPALIVE_DISABLE_SAFARI))
       {
    

Best regards,
Piotr S. < [email protected] >

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs