Nginx + PHP-FPM is very slow on Mountain Lion

Question

I have set up Nginx with PHP-FPM on my MacBook running ML. It works fine but it takes between 5 and 10 seconds to connect when I run a page in my browser. Even the following PHP script:

<?php
die();

takes about 5 seconds to connect. I am using Chrome and I get the "Sending request" message in the status bar for around 7 seconds. If I refresh again it seems to work instantly, but if I leave it for around 10 seconds it will "sleep" again. It is as if nginx or PHP is going to sleep and then taking ages to wake up again.

Edit: This is also affecting static files on the server so it would seem to be an issue with DNS or nginx.

Can anyone help me figure out what is causing this?

nginx.conf

worker_processes 2;

events {
   worker_connections 1024;
}

http {
    include mime.types;
   default_type text/plain;
   server_tokens off;
   sendfile on;
   tcp_nopush on;
   keepalive_timeout 1;
   gzip on;
   gzip_comp_level 2;
   gzip_proxied any;
   gzip_types text/plain text/css text/javascript application/json application/x-javascript text/xml application/xml application/xml+rss;

   index index.html index.php;

   upstream www-upstream-pool{
      server unix:/tmp/php-fpm.sock;
   }

  include sites-enabled/*;
}

php-fpm.conf

[global]
pid = /usr/local/etc/php/var/run/php-fpm.pid
; run in background or in foreground?
; set daemonize = no for debugging
                         daemonize = yes

include=/usr/local/etc/php/5.4/pool.d/*.conf

pool.conf

[www]
user=matt
group=staff
pm = dynamic
pm.max_children = 10
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500
listen = /tmp/php-fpm.sock
;listen = 127.0.0.1:9000
php_flag[display_errors] = off

sites-available/cft

server {
   listen 80;
   server_name cft.local;
   root /Users/matt/Sites/cft/www;
   access_log /Users/matt/Sites/cft/log/access.log;
   error_log /Users/matt/Sites/cft/log/error.log;
   index index.php;

   location / {
      try_files $uri $uri/ /index.php?$args;
   }

   include fastcgi_php_default.conf;
}

fastcgi_php_default.conf

fastcgi_intercept_errors on;

location ~ .php$
    {
    fastcgi_split_path_info ^(.+.php)(/.+)$;

    fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
    fastcgi_param  QUERY_STRING       $query_string;
    fastcgi_param  REQUEST_METHOD     $request_method;
    fastcgi_param  CONTENT_TYPE       $content_type;
    fastcgi_param  CONTENT_LENGTH     $content_length;

    fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
    fastcgi_param  REQUEST_URI        $request_uri;
    fastcgi_param  DOCUMENT_URI       $document_uri;
    fastcgi_param  DOCUMENT_ROOT      $document_root;
    fastcgi_param  SERVER_PROTOCOL    $server_protocol;
    fastcgi_param  HTTPS              $https if_not_empty;

    fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
    fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

    fastcgi_param  REMOTE_ADDR        $remote_addr;
    fastcgi_param  REMOTE_PORT        $remote_port;
    fastcgi_param  SERVER_ADDR        $server_addr;
    fastcgi_param  SERVER_PORT        $server_port;
    fastcgi_param  SERVER_NAME        $server_name;

    fastcgi_param PATH_INFO         $fastcgi_path_info;
    fastcgi_param PATH_TRANSLATED   $document_root$fastcgi_path_info;

    fastcgi_read_timeout 300;

    fastcgi_pass www-upstream-pool;

    fastcgi_index index.php;
}

fastcgi_param  REDIRECT_STATUS    200;

Answer 1

One reason could be - as already suspected above - that your server works perfectly but there is something wrong with DNS lookups.

Such long times usually are caused by try + timeout, then retry other way, works, cache.

Caching of the working request would explain why your second http request is fast.

I am almost sure, that this is caused by a DNS lookup, which tries to query an unreachable service, gives up after a timeout period, then tries a working service and caches the result for a couple of minutes.

Apple has recently made a significant change in how the OS handles requests for ".local" name resolution that can adversely affect Active Directory authentication and DFS resolution.

When processing a ".local" request, the Mac OS now sends a Multicast DNS (mDNS) or broadcast, then waits for that request to timeout before correctly sending the information to the DNS server. The delay caused by this results in an authentication failure in most cases.

http://www.thursby.com/local-domain-login-10.7.html

They are offering to set the timeout to the smallest possible value, which apparently is still 1 second - not really satisfying.

I suggest to use localhost or 127.0.0.1 or try http://test.dev as a local domain

/etc/hosts

127.0.0.1 localhost test.dev

EDIT In OSX .local really seems to be a reserved tld for LAN devices. Using another domain like suggested above will def. solve this problem

http://support.apple.com/kb/HT3473

EDIT 2 Found this great article which exactly describes your problem and how to solve it

http://www.dmitry-dulepov.com/2012/07/os-x-lion-and-local-dns-issues.html?m=1

Answer 2

I can't see anything in your configuration that would cause this behaviour alone. Since the configuration of Nginx looks OK, and this affects both static and CGI request, I would suspect it is a system issue.

An issue that might be worth investigating is whether the problem is being caused by IPv6 negotiation on your server.

If you are using loopback (127.0.0.1) as your listen address, have a look in /etc/hosts and ensure that the following lines are present:

::1    localhost6.localdomain6 localhost6
::1    site.local cft.local

If this doesn't resolve the issue, I'm afraid you'll need to look at more advanced diagnostics, perhaps using strace or similar on the Nginx instance.