macos - Nginx + PHP-FPM 在 Mountain Lion 上非常慢

Question

我已经在运行 ML 的 MacBook 上使用 PHP-FPM 设置了 Nginx。它工作很好，但是当我在浏览器中运行页面时需要 5 到 10 秒才能连接。甚至是以下 PHP 脚本:

<?php
die();

连接大约需要 5 秒。我正在使用 Chrome，我在状态栏中收到“发送请求”消息大约 7 秒钟。如果我再次刷新它似乎立即工作，但如果我离开它大约 10 秒它会再次“休眠”。就好像 nginx 或 PHP 将要休眠，然后需要很长时间才能再次醒来。

编辑:这也会影响服务器上的静态文件，因此它似乎是 DNS 或 nginx 的问题。

谁能帮我弄清楚是什么原因造成的？

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

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

可用站点/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

一个原因可能是 - 正如上面已经怀疑的那样 - 您的服务器运行正常但 DNS 查找有问题。

这么长的时间一般是try+timeout导致的，然后换个方式重试，works，cache。

工作请求的缓存可以解释为什么你的第二个 http 请求很快。

我几乎可以肯定，这是由 DNS 查找引起的，它尝试查询无法访问的服务，在超时后放弃，然后尝试工作服务并将结果缓存几分钟。

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

他们提议将超时设置为尽可能小的值，显然仍然是 1 秒 - 不太令人满意。

我建议使用 localhost 或 127.0.0.1 或尝试 http://test.dev作为本地域

/etc/主机

127.0.0.1 localhost test.dev

编辑在 OSX 中，.local 似乎真的是为 LAN 设备保留的顶级域名。使用上面建议的另一个域将 def。解决这个问题

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

编辑 2找到了这篇很好的文章，它准确地描述了您的问题以及如何解决它

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