Nginx開発ガイド2:プロファイル実装phpとfile構成例
9470 ワード
ここでは主にnginxの静的構成を紹介し,最後にnginxベースのphpウェブページアクセスサービスおよびファイルアクセスサービスを構築する.上記のインストールガイドに続く、デフォルトのプロファイルは/usr/local/nginx/conf/nginxである.conf、その一部のコードは以下の通りです.
モジュールをいくつか分けます.
1.プロセス構成
プロセス構成命令はいかなる構成モジュールにも属さず、全ローカルエリアでしか構成できない.主なパラメータは以下の通りである.
worker_processes:
ワークフローの数を表します.デフォルトは1です.通常、設定数はCPUコア数と同じです.この場合、ワークフローごとに独立したCPUコアで動作し、スケジューリングコストを完全に排除します.もちろん、ここではパラメータワークフローが必要です.cpu_affinityの連携、例えば以下の設定
ここでは、CPUコア0/1/2/3上でそれぞれ実行される4つのプロセスを示し、各CPUコアは1つのマスクで表され、2つのプロセスがそれぞれ2つのCPUコア上で実行される場合は、次のように表される.
すなわち、プロセス1はコア0/2で実行され、プロセス2はコア1/3で実行される.8プロセスはそれぞれ8つのCPUコアに以下のように表示される.
master_process on | off:
Nginxがプロセスプールを起動するかどうかを示します.デフォルトはONです.そうしないとmasterプロセスは確立されず、同時性が大幅に低下します.我々が実験した物理マシンを例にworkerを設定しますprocessesは2で、ps aux|grep nginxを入力した結果は以下の通りです.
1つのmasterプロセスと2つのworkerプロセスが起動することがわかります.
daemon on | off:
プロセスを保護してnginxを実行するかどうか、デフォルトはonです.dockerでoffに設定することに注意してください.その原理と意味は後述します.
working_directory path;
Nginxの作業ディレクトリを構成します.coredumpファイルが格納されています.予期せぬクラッシュが発生した場合、gdbデバッグで原因を検索できます.
worker_shutdown_timeout time;
実行を停止すると、Nginxは最大どのくらい待ってからプロセスを強制的に閉じるかを示します.
2.ダイナミックモジュール構成
load_module file;
このモジュールは、再./configure&&make&make install、動的ロードモジュールの個数制限は128個で、すでにロードされている動的モジュールが変更されている場合はTengineを再起動しなければ有効ではなく、httpモジュールのみをサポートします.fileはモジュール名、絶対パス、相対パス、デフォルトの検索パスは/usr/local/nginxディレクトリです.load_moduleも同様にグローバル構成が必要です.
3.ログ構成の実行
error_log file|stderr level;
access_log file|stderr level;
ログは主に、TCP/HTTPアクセス要求のaccess_の2種類に分けられます.logとサーバエラー情報を記録するerror_log、デフォルトはインストールディレクトリの下のファイル/usr/local/nginx/logs/accessです.logおよび/usr/local/nginx/logs/error.log.パラメータ2レベルはログの許可出力レベルです.
4.events構成
Nginxはイベント駆動を採用し、カーネルが提供するepoll、kqueueを利用してネットワーク接続を効率的に処理し、eventsはNginxのイベント駆動メカニズムを構成するために使用される.
use_method;
イベントの処理方法は、linuxでselect、poll、epollを選択できます.ここで、epollは大きなリクエスト量で最も効率的です.これはNginxのデフォルト設定なので、一般的に変更する必要はありません.Windowsではselectとiocpが使用できます.iocpは通常最も効率的で、デフォルトです.
accept_mutex on | off;
負荷分散をオンにするかどうかは、複数のworkerプロセスのワークロードをより均一にすることができますが、ロックのコストが高く、効率に影響します.デフォルトはoffで、負荷分散は有効ではありません.しかし、現在のNginxでは、EPOLLEXCLUSIVEやreuseportなどのカーネルレベルの負荷等化技術も使用できます.
worker_connections number;
ワークプロセスで処理できる最大接続数.
5.http構成
この部分は複雑ですが、ここではphpウェブページサービスとファイルアクセスサービスの構築について説明し、Nginxはhttpブロックを使用してhttp関連のすべての機能を構成します.cache、fastcgi、gzip、sever、location、proxy、upstreamなどが含まれています.httpを構成するphpサービスとファイルアクセスサービスの例を直接示します.
server構成:server命令は1つの仮想ホストを定義して、それは1つの構成モジュールでなければならなくて、server命令を使って1つの仮想ホストを定義して、それは1つの構成モジュールでなければならなくて、ブロックの内部でその他の命令を使ってホストのポート番号、ドメイン名などのパラメータを確定して、このようにNginxは対外的にWebサービスを提供することができます.
Listen portは仮想ホストが傍受するポートを設定し、デフォルトは80であり、同じIPアドレス、SSL、recvbuf/sndbuf、HTTP 2である.0はlisten設定でサポートできますserver_name仮想ホストが外部にサービスを提供するホスト名を設定します.
locationは,クライアント要求のURIにパターンを指定することで一致し,基本構文は以下の通りである.location[=|~|~*^~|@]pattern{......}であり,ルールは以下の通りである.
~#波線は正則マッチングを実行し、大文字と小文字を区別することを表す.~*#は、大文字と小文字を区別せずに正規マッチングを実行することを示します.^~#^~は通常の文字マッチングを表し、このオプションが一致すると、そのオプションのみが一致し、他のオプションと一致せず、一般的にディレクトリマッチングに使用される.=#通常の文字を正確に一致させる;@#"@"は、内部配向時にerror_などのネーミングされたlocationを定義します.page, try_files.
次に、phpウェブサービスを通じて、上のプロファイルと結びつけて、serverモジュールの機能を具体的に説明します.phpウェブサービスを実現するには、必要なソフトウェアをインストールする必要があります.
php-frmの構成
nginxは高性能のhttpサーバと逆プロキシサーバです.すなわちnginxは,1つのHTTPサーバとしてウェブサイトの公開処理を行うこともできるし,1つの逆エージェントサーバとして負荷等化を行うこともできる.ただし、nginx自体はphpファイルを解析しないことに注意してください.PHPページに対する要求はnginxによってFastCGIプロセスが傍受するIPアドレスおよびポートに渡され、php-fpm(サードパーティのfastcgiプロセスマネージャ)が動的解析サーバとして処理し、最後に処理結果をnginxに返す.すなわち,nginxは逆エージェント機能により動的要求をバックエンドphp−fpmに転向し,PHPの解析サポートを実現することが,NginxがPHPの動的解析を実現する基本原理である.いくつかの基本的な概念(nginx+php-fpm+fastcgi):
1)Nginxは
2)PHP-FPMはブロックされた単一スレッドモデルであり、
3)fastCGI:php,python解釈器などの異なる言語解釈器とwebserverとの通信を解決するためにcgiプロトコルが出現した.cgiプロトコルに従ってプログラムを作成すれば、言語解釈器とwebwerverの通信を実現できます.php-cgiプログラムのようです.しかしwebserverはリクエストを受信するたびにforkのcgiプロセスに行き、リクエストが終了してからkillがこのプロセスを削除します.このように10000個の要求があればfork,kill php−cgiプロセス10000回が必要である.fastcgiはcgiの改良バージョンです.fast-cgiはリクエストを処理するたびに、このプロセスをkillするのではなく、このプロセスを保持し、このプロセスが複数のリクエストを一度に処理できるようにします.効率が大幅に向上した.
最初のserverのlocationの構成を見てみましょう.
location ~\.phpは、phpリクエストを大文字と小文字で敏感に処理することを示す.
fastcgi_passはfastcgiバインドのアドレスとポートを表します.
fastcgi_param SCRIPT_FILENAMEは、スクリプトファイル要求のパス、すなわちアクセス127.0を表す.0.1/*.phpの場合、サイトのルートディレクトリの下の名前を*と読む必要があります.phpのファイルは、ない場合はエラーを返します.ディレクトリ/home/data/ngnix/php_study/wwwで読み込みます.
127.0で.0.1:80/A/B?c=1&d=4を例にとると、httpリクエストが到来すると、解析プロセスは以下のようになる.
1.nginxはhttpリクエストを受信し、傍受されたポート番号に基づいて対応するserverに一致する.
2.受け取ったURIを照合し、location/に照合する.この照合規則ではtry_filesはまずrootディレクトリ(/home/data/ngnix/php_study/www)でペアファイルがあるかどうかを探します.ない場合は、rootディレクトリの下に$uri/ディレクトリがあるかどうかを確認します.同様に一致しなければ、最後の項目/indexに一致する.php?$args、すなわち「内部サブリクエスト」を発行することは、nginxがhttpリクエストを127.0に開始したことに相当する.0.1:80/index.php?c=1&d=4
3.このサブリクエストは
phpファイル(php_など)をinfo.phpはディレクトリ/home/data/ngnix/php_に配置study/wwwで、http://127.0.0.1/php_info.phpにアクセスします.
次に、別のserverモジュールに対応する静的ファイルアクセス構成、すなわちfile構成を参照します.
ファイル・アクセスの構成は簡単です.主に次のパラメータに関連します.
root path;
ドキュメントのルートディレクトリを要求し、pathを実パスとしてファイルを検索します.この構成が完了すると、http://127.0.0.1:8080/ディレクトリ/home/data/filedown/に静的Webページでアクセスします.
user root;
worker_processes 2;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"'モジュールをいくつか分けます.
1.プロセス構成
プロセス構成命令はいかなる構成モジュールにも属さず、全ローカルエリアでしか構成できない.主なパラメータは以下の通りである.
worker_processes:
ワークフローの数を表します.デフォルトは1です.通常、設定数はCPUコア数と同じです.この場合、ワークフローごとに独立したCPUコアで動作し、スケジューリングコストを完全に排除します.もちろん、ここではパラメータワークフローが必要です.cpu_affinityの連携、例えば以下の設定
worker_processes 4；
worker_cpu_affinity 0001 0010 0100 1000；ここでは、CPUコア0/1/2/3上でそれぞれ実行される4つのプロセスを示し、各CPUコアは1つのマスクで表され、2つのプロセスがそれぞれ2つのCPUコア上で実行される場合は、次のように表される.
worker_processes 2;
worker_cpu_affinity 0101 1010;
すなわち、プロセス1はコア0/2で実行され、プロセス2はコア1/3で実行される.8プロセスはそれぞれ8つのCPUコアに以下のように表示される.
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
master_process on | off:
Nginxがプロセスプールを起動するかどうかを示します.デフォルトはONです.そうしないとmasterプロセスは確立されず、同時性が大幅に低下します.我々が実験した物理マシンを例にworkerを設定しますprocessesは2で、ps aux|grep nginxを入力した結果は以下の通りです.
root 3648 0.0 0.0 24916 464 ? Ss 11:43 0:00 nginx: master process /usr/local/nginx/sbin/nginx
root 3649 0.0 0.0 25296 2564 ? S 11:43 0:00 nginx: worker process
root 3650 0.0 0.0 25296 2564 ? S 11:43 0:00 nginx: worker process
root 4001 0.0 0.0 21312 1020 pts/18 S+ 11:47 0:00 grep --color=auto nginx
1つのmasterプロセスと2つのworkerプロセスが起動することがわかります.
daemon on | off:
プロセスを保護してnginxを実行するかどうか、デフォルトはonです.dockerでoffに設定することに注意してください.その原理と意味は後述します.
working_directory path;
Nginxの作業ディレクトリを構成します.coredumpファイルが格納されています.予期せぬクラッシュが発生した場合、gdbデバッグで原因を検索できます.
worker_shutdown_timeout time;
実行を停止すると、Nginxは最大どのくらい待ってからプロセスを強制的に閉じるかを示します.
2.ダイナミックモジュール構成
load_module file;
このモジュールは、再./configure&&make&make install、動的ロードモジュールの個数制限は128個で、すでにロードされている動的モジュールが変更されている場合はTengineを再起動しなければ有効ではなく、httpモジュールのみをサポートします.fileはモジュール名、絶対パス、相対パス、デフォルトの検索パスは/usr/local/nginxディレクトリです.load_moduleも同様にグローバル構成が必要です.
3.ログ構成の実行
error_log file|stderr level;
access_log file|stderr level;
ログは主に、TCP/HTTPアクセス要求のaccess_の2種類に分けられます.logとサーバエラー情報を記録するerror_log、デフォルトはインストールディレクトリの下のファイル/usr/local/nginx/logs/accessです.logおよび/usr/local/nginx/logs/error.log.パラメータ2レベルはログの許可出力レベルです.
4.events構成
Nginxはイベント駆動を採用し、カーネルが提供するepoll、kqueueを利用してネットワーク接続を効率的に処理し、eventsはNginxのイベント駆動メカニズムを構成するために使用される.
use_method;
イベントの処理方法は、linuxでselect、poll、epollを選択できます.ここで、epollは大きなリクエスト量で最も効率的です.これはNginxのデフォルト設定なので、一般的に変更する必要はありません.Windowsではselectとiocpが使用できます.iocpは通常最も効率的で、デフォルトです.
accept_mutex on | off;
負荷分散をオンにするかどうかは、複数のworkerプロセスのワークロードをより均一にすることができますが、ロックのコストが高く、効率に影響します.デフォルトはoffで、負荷分散は有効ではありません.しかし、現在のNginxでは、EPOLLEXCLUSIVEやreuseportなどのカーネルレベルの負荷等化技術も使用できます.
worker_connections number;
ワークプロセスで処理できる最大接続数.
5.http構成
この部分は複雑ですが、ここではphpウェブページサービスとファイルアクセスサービスの構築について説明し、Nginxはhttpブロックを使用してhttp関連のすべての機能を構成します.cache、fastcgi、gzip、sever、location、proxy、upstreamなどが含まれています.httpを構成するphpサービスとファイルアクセスサービスの例を直接示します.
http {
include mime.types;
default_type application/octet-stream;
#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
server {
listen 80;
server_name localhost;
root /home/data/ngnix/php_study/www;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
#root php;
index index.php index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/data/ngnix/php_study/www$fastcgi_script_name;
include fastcgi_params;
}
}
autoindex on;
autoindex_exact_size on;
autoindex_localtime on;
server {
listen 8080 default_server;
listen [::]:8080 default_server;
server_name _;
root /home/data/filedown/;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
}
server構成:server命令は1つの仮想ホストを定義して、それは1つの構成モジュールでなければならなくて、server命令を使って1つの仮想ホストを定義して、それは1つの構成モジュールでなければならなくて、ブロックの内部でその他の命令を使ってホストのポート番号、ドメイン名などのパラメータを確定して、このようにNginxは対外的にWebサービスを提供することができます.
Listen portは仮想ホストが傍受するポートを設定し、デフォルトは80であり、同じIPアドレス、SSL、recvbuf/sndbuf、HTTP 2である.0はlisten設定でサポートできますserver_name仮想ホストが外部にサービスを提供するホスト名を設定します.
locationは,クライアント要求のURIにパターンを指定することで一致し,基本構文は以下の通りである.location[=|~|~*^~|@]pattern{......}であり,ルールは以下の通りである.
~#波線は正則マッチングを実行し、大文字と小文字を区別することを表す.~*#は、大文字と小文字を区別せずに正規マッチングを実行することを示します.^~#^~は通常の文字マッチングを表し、このオプションが一致すると、そのオプションのみが一致し、他のオプションと一致せず、一般的にディレクトリマッチングに使用される.=#通常の文字を正確に一致させる;@#"@"は、内部配向時にerror_などのネーミングされたlocationを定義します.page, try_files.
次に、phpウェブサービスを通じて、上のプロファイルと結びつけて、serverモジュールの機能を具体的に説明します.phpウェブサービスを実現するには、必要なソフトウェアをインストールする必要があります.
#
sudo apt-get install php7.2
sudo apt-get install php7.2-fpm
sudo apt-get install nginx
#
sudo apt-get install php-json
sudo apt-get install php-curl
sudo apt-get install php7.2-mysql
sudo apt-get install php7.2-cgiphp-frmの構成
sudo gedit /etc/php/7.2/fpm/php.ini
# ：
# 778 ;cgi.fix_fathinfo=1 cgi.fix_fathinfo=0nginxは高性能のhttpサーバと逆プロキシサーバです.すなわちnginxは,1つのHTTPサーバとしてウェブサイトの公開処理を行うこともできるし,1つの逆エージェントサーバとして負荷等化を行うこともできる.ただし、nginx自体はphpファイルを解析しないことに注意してください.PHPページに対する要求はnginxによってFastCGIプロセスが傍受するIPアドレスおよびポートに渡され、php-fpm(サードパーティのfastcgiプロセスマネージャ)が動的解析サーバとして処理し、最後に処理結果をnginxに返す.すなわち,nginxは逆エージェント機能により動的要求をバックエンドphp−fpmに転向し,PHPの解析サポートを実現することが,NginxがPHPの動的解析を実現する基本原理である.いくつかの基本的な概念(nginx+php-fpm+fastcgi):
1)Nginxは
IO & IO モデルであり,オペレーティングシステムが提供するepollのような機能により,1つのスレッドで複数のクライアントの要求を処理することができる.Nginxのプロセスはスレッドであり、各プロセスには1つのスレッドしかありませんが、このスレッドは複数のクライアントに非同期で同時にサービスすることができます.つまり、前のリクエストが処理されたかどうかにかかわらず、新しいリクエストを絶えず受信することができます.2)PHP-FPMはブロックされた単一スレッドモデルであり、
pm.max_childrenは最大のプロセス数を指定し、pm.max_requestsはプロセスごとに何個の要求を処理した後に再起動することを指定する(PHPはたまにメモリ漏れがあるため、再起動する必要がある).PHP-FPMの各プロセスにも1つのスレッドしかありませんが、1つのプロセスは同時に1つのクライアントにしかサービスできません.すなわち、次のリクエストを処理するには、完全なリクエストを処理しなければなりません.3)fastCGI:php,python解釈器などの異なる言語解釈器とwebserverとの通信を解決するためにcgiプロトコルが出現した.cgiプロトコルに従ってプログラムを作成すれば、言語解釈器とwebwerverの通信を実現できます.php-cgiプログラムのようです.しかしwebserverはリクエストを受信するたびにforkのcgiプロセスに行き、リクエストが終了してからkillがこのプロセスを削除します.このように10000個の要求があればfork,kill php−cgiプロセス10000回が必要である.fastcgiはcgiの改良バージョンです.fast-cgiはリクエストを処理するたびに、このプロセスをkillするのではなく、このプロセスを保持し、このプロセスが複数のリクエストを一度に処理できるようにします.効率が大幅に向上した.
最初のserverのlocationの構成を見てみましょう.
location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/data/ngnix/php_study/www$fastcgi_script_name;
include fastcgi_params;
}location ~\.phpは、phpリクエストを大文字と小文字で敏感に処理することを示す.
fastcgi_passはfastcgiバインドのアドレスとポートを表します.
fastcgi_param SCRIPT_FILENAMEは、スクリプトファイル要求のパス、すなわちアクセス127.0を表す.0.1/*.phpの場合、サイトのルートディレクトリの下の名前を*と読む必要があります.phpのファイルは、ない場合はエラーを返します.ディレクトリ/home/data/ngnix/php_study/wwwで読み込みます.
127.0で.0.1:80/A/B?c=1&d=4を例にとると、httpリクエストが到来すると、解析プロセスは以下のようになる.
1.nginxはhttpリクエストを受信し、傍受されたポート番号に基づいて対応するserverに一致する.
2.受け取ったURIを照合し、location/に照合する.この照合規則ではtry_filesはまずrootディレクトリ(/home/data/ngnix/php_study/www)でペアファイルがあるかどうかを探します.ない場合は、rootディレクトリの下に$uri/ディレクトリがあるかどうかを確認します.同様に一致しなければ、最後の項目/indexに一致する.php?$args、すなわち「内部サブリクエスト」を発行することは、nginxがhttpリクエストを127.0に開始したことに相当する.0.1:80/index.php?c=1&d=4
3.このサブリクエストは
location ~ \.php${ ... } catch、すなわちFastCGIのハンドラに入り、nginxはFastCGIモジュール構成により、関連phpパラメータをphp-fpm処理に渡す必要がある.この項目にfastcgi_が設定されていますpass関連パラメータは,ユーザが要求したリソースをphp−fpmに送って解析する.phpファイル(php_など)をinfo.phpはディレクトリ/home/data/ngnix/php_に配置study/wwwで、http://127.0.0.1/php_info.phpにアクセスします.
次に、別のserverモジュールに対応する静的ファイルアクセス構成、すなわちfile構成を参照します.
server {
listen 8080 default_server;
listen [::]:8080 default_server;
server_name _;
root /home/data/filedown/;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}ファイル・アクセスの構成は簡単です.主に次のパラメータに関連します.
root path;
ドキュメントのルートディレクトリを要求し、pathを実パスとしてファイルを検索します.この構成が完了すると、http://127.0.0.1:8080/ディレクトリ/home/data/filedown/に静的Webページでアクセスします.