我在运行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;
答案 0 :(得分:9)
有一个原因 - 正如上面已经怀疑的那样 - 您的服务器运行正常,但DNS查找有问题。
如此长的时间通常是由try + timeout引起的,然后以其他方式重试,工作,缓存。
缓存工作请求可以解释为什么第二个http请求很快。
我几乎可以肯定,这是由DNS查找引起的,它试图查询无法访问的服务,在超时时间后放弃,然后尝试工作服务并将结果缓存几分钟。
Apple最近对操作系统处理“.local”名称解析请求的方式进行了重大更改,这些请求可能会对Active Directory身份验证和DFS解析产生负面影响。
当处理“.local”请求时,Mac OS现在发送多播DNS(mDNS)或广播,然后在将信息正确发送到DNS服务器之前等待该请求超时。由此导致的延迟在大多数情况下会导致身份验证失败。
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设备的保留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
答案 1 :(得分:2)
我在配置中看不到会导致此行为的任何内容。由于Nginx的配置看起来不错,这会影响静态和CGI请求,我怀疑它是系统问题。
可能值得研究的问题是问题是否是由服务器上的IPv6协商引起的。
如果您使用环回(127.0.0.1)作为收听地址,请查看/etc/hosts
并确保存在以下行:
::1 localhost6.localdomain6 localhost6
::1 site.local cft.local
如果这不能解决问题,我担心您需要查看更高级的诊断,可能在Nginx实例上使用strace或类似的。
答案 2 :(得分:0)
(这是作为评论开始的,但它有点长)
这里有一些非常破碎的东西 - 但我在配置中没有看到任何明显的东西来解释它。我首先在请求进行时查看top和netstat,并在处理完请求后检查日志(webserver和system)。如果仍然没有显示任何内容,那么下一站就是捕获所有网络流量 - 这种长时间延迟的最可能原因是身份/ DNS查找失败。
答案 3 :(得分:0)
除非出现任何与配置相关的问题,否则可能是编译问题。
我建议您从自制软件OS X开源软件包管理器安装nginx。
如果你还没有自制软件(并且每个开发人员都应该!),你可以抓住it from here或者在终端中运行它:
ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"
然后运行
brew install ngnix
ngnix将从自制软件库部署。显然,你要确保先删除旧的nginx副本。
我推荐这个的原因是,自制软件为每个需要它的开源库提供了许多特定于OS X的补丁,并且被社区大量使用和测试。我过去在OS X上使用了自制软件中的nginx,没有任何问题可以说。