我在运行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
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
网站可用/ 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;
如此长的时间通常是由尝试超时引起的,然后重试其他方式,工作,缓存.
缓存工作请求可以解释为什么第二个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 / hosts文件
127.0.0.1 localhost test.dev
编辑
在OSX中,.local似乎是LAN设备的保留tld.使用上面建议的其他域名将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