Nginx + PHP-FPM is very slow on Mountain Lion - macos

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.

Answer 3

(this started as a comment but it's getting a bit long)
There's something very broken here - but I don't see anything obvious in your config to explain it. I'd start by looking at top and netstat while the request is in progress, and checking your logs (webserver and system) after the request has been processed. If that still reveals nothing, then next stop would be to capture all the network traffic - most likely causes for such a long delay are failed ident / DNS lookups.

Answer 4

Barring any configuration-related issues, it may be a compile issue.
I would advise that you install nginx from homebrew, the OS X open source package manager.
If you don't yet have homebrew (and every developer should!), you can grab it from here or just run this in a terminal:
ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"
Then run
brew install ngnix
And ngnix will be deployed from the homebrew repository. Obviously, you'll want to make sure that you removed your old copy of nginx first.
The reason I recommend this is that homebrew has a number of OS X-specific patches for each open source library that needs it and is heavily used and tested by the community. I've used nginx from homebrew in the past on OS X and had no problems to speak of.