6

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;
4

4 に答える 4

12

1つの理由は、上記ですでに疑われているように、サーバーは完全に機能しているが、DNSルックアップに問題があることである可能性があります。

このような長い時間は通常、try + timeoutが原因で発生し、その後、他の方法で再試行し、機能し、キャッシュします。

作業中のリクエストをキャッシュすると、2番目のhttpリクエストが高速である理由がわかります。

これは、到達不能なサービスのクエリを試行し、タイムアウト期間後にあきらめて、動作中のサービスを試行し、結果を数分間キャッシュするDNSルックアップが原因であるとほぼ確信しています。

Appleは最近、ActiveDirectory認証とDFS解決に悪影響を与える可能性のある「.local」名前解決の要求をOSが処理する方法に大幅な変更を加えました。

「.local」リクエストを処理するとき、Mac OSはマルチキャストDNS(mDNS)またはブロードキャストを送信し、そのリクエストがタイムアウトするのを待ってから、DNSサーバーに情報を正しく送信します。これによって引き起こされる遅延は、ほとんどの場合、認証の失敗につながります。

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

彼らはタイムアウトを可能な限り最小の値に設定することを提案していますが、それは明らかにまだ1秒であり、実際には満足のいくものではありません。

ローカルホストまたは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

于 2013-01-13T14:07:49.380 に答える
3

この動作だけを引き起こす構成には何も見えません。Nginx の構成は問題ないように見え、これは静的要求と CGI 要求の両方に影響するため、システムの問題であると思われます。

調査する価値のある問題は、問題がサーバー上の IPv6 ネゴシエーションによって引き起こされているかどうかです。

ループバック (127.0.0.1) をリッスン アドレスとして使用している場合は/etc/hosts、次の行が存在することを確認してください。

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

これで問題が解決しない場合は、おそらくNginx インスタンスでstraceなどを使用して、より高度な診断を行う必要があります。

于 2013-01-12T16:17:24.280 に答える
0

構成関連の問題がなければ、コンパイルの問題である可能性があります。

OS X のオープン ソース パッケージ マネージャーである homebrew から nginx をインストールすることをお勧めします。

まだ自作を持っていない場合 (すべての開発者がそうすべきです!)、ここから取得するか、ターミナルでこれを実行するだけです:

ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"

次に実行します

brew install ngnix

ngnix は homebrew リポジトリからデプロイされます。明らかに、最初に nginx の古いコピーを削除したことを確認する必要があります。

私がこれを推奨する理由は、homebrew には、それを必要とするオープンソース ライブラリごとに多数の OS X 固有のパッチがあり、コミュニティによって頻繁に使用およびテストされているためです。OS Xで過去に自作のnginxを使用しましたが、問題はありませんでした。

于 2013-01-12T17:07:11.180 に答える
0

(これはコメントとして始まりましたが、少し長くなりました)

ここには非常に壊れたものがあります-しかし、それを説明するためにあなたの設定に明らかなものは何もありません. リクエストの進行中に top と netstat を確認し、リクエストが処理された後にログ (Web サーバーとシステム) を確認することから始めます。それでも何も明らかにならない場合は、次の目的はすべてのネットワーク トラフィックをキャプチャすることです。このような長い遅延の原因として最も可能性が高いのは、ident/DNS ルックアップの失敗です。

于 2013-01-08T09:25:12.537 に答える