nginxの基本構成の詳細

1. Apache サーバーと nginx の長所と短所:
私たちはこれまで Apache を HTTPServer として広く使用してきました。
Apache は優れたパフォーマンスを持ち、モジュールを通じてさまざまな豊富な機能を提供できます。
1) まず第一に、Apache のクライアントへの応答は同時実行をサポートします。httpd デーモン プロセスを実行すると、複数の子プロセス/スレッドが同時に生成され、各子プロセス/スレッドがそれぞれクライアントのリクエストに応答します。 2) さらに、Apache は静的サービスと動的サービスを提供できます。たとえば、PHP の解析は、パフォーマンスの低い CGI ではなく、PHP をサポートするモジュール (通常は mod_php5 または apxs2) を通じて実装されます。
3) デメリット:
したがって、通常 Apache と呼ばれるこのタイプのサーバーは、各ユーザーのリクエストに応答するために子プロセス/スレッドを作成する必要があるため、マルチプロセス HTTP サーバーであるプロセスベースのサーバーになります。 この欠点は、同時リクエストが多数ある場合 (これは大規模なポータルでは非常に一般的です)、大量のスレッドが必要となり、多くのシステム リソース、CPU、メモリを占有することです。したがって、同時処理は Apache の強みではありません。
4)解決策:
現在、非同期サーバーと呼ばれる、同時実行性の点で優れたパフォーマンスを発揮する別の Web サーバーがあります。最も有名なものは Nginx と Lighttpd です。いわゆる非同期サーバーは、ユーザーからの同時要求が通常 1 つまたは複数のスレッドのみを必要とする点を除いて、イベント駆動型プログラミング モデルではイベント駆動型です。したがって、システム リソースをほとんど消費しません。これらのタイプは、軽量 Web サーバーとも呼ばれます。
たとえば、10,000 の同時接続リクエストの場合、nginx は数 MB のメモリしか使用しませんが、Apache は数百 MB のメモリ リソースを使用する必要がある場合があります。
2. 実際の単回使用:
1) Apache を単独で HTTP サーバーとして使用する方法については、これ以上説明する必要はありません。これは非常に一般的なアプリケーションです。 Apache による PHP などのサーバーサイド スクリプトのサポートは独自のモジュールを通じて実装されており、そのパフォーマンスが優れていることを上で紹介しました。
2) nginx または lighttpd を単独で HTTPServer として使用することもできます。
Apache と同様に、nginx と lighttpd は、さまざまなモジュールを通じてサーバーの機能を強化できます。また、conf 構成ファイルを通じてさまざまなオプションを構成できます。
PHP などの場合、nginx にも lighttpd にも PHP をサポートする組み込みモジュールはありませんが、FastCGI を通じてサポートされます。
Lighttpd は、モジュールを通じて CGI、FastCGI、および SCGI サービスを提供でき、外部で生成されたプロセスを使用するだけでなく、FastCGI バックエンドを自動的に生成することもできます。 nginx は PHP 自体を処理する機能を提供しておらず、サードパーティのモジュールを通じて PHP の FastCGI 統合を提供する必要があります。

------------------------ http://bbs.it-home.org/ 以外のすべての Visits=> を書き換えます; http://bbs.it-home.org/
サーバー名 web90.***.com;

if ($host = "web90.***.com") {
書き換えます ^(.*)$ http://bbs.it-home.org/$1 Permanent;
}

----------------------------------nginx の停止/スムーズな再起動#p#ページング タイトル#e#

nginx シグナル制御

TERM、INTはすぐに締め切ります
やめて静かに閉じてください
HUP スムーズな再起動、設定ファイルのリロード
USR1 はログ ファイルを再度開きます。これは、ログを切り取るときに便利です
USR2 実行可能プログラムをスムーズにアップグレード
WINCHは作業プロセスを優雅に閉じます


1) 落ち着いて停止します:

kill -QUIT Nginx メインプロセス ID

kill -QUIT '/usr/local/webserver/nginx/logs/nginx.pid'


2) クイックストップ:

kill -TERM Nginx メインプロセス ID

kill -TERM '/usr/local/webserver/nginx/logs/nginx.pid'

kill -INTN ginx メインプロセス番号

kill -INT '/usr/local/webserver/nginx/logs/nginx.pid'

3) すべての nginx プロセスを強制停止します

pkill -9 nginx


1) スムーズな再起動

kill -HUP nginx メインプロセス ID

kill -HUP '/usr/local/webserver/nginx/logs/nginx.pid'

------------------------nginx.conf
#p#ページングタイトル#e#


ワーカープロセス 8;

ジョブ生成プロセスの数を指定します

通常、CPU の合計コア数または合計コア数の 2 倍に等しくなります。たとえば、2 つのクアッドコア CPU の場合、コアの合計数は 8 です。 //使用されるネットワーク I/O モデル、Linux システムは epoll、FreeBSD は kqueue

を推奨 work_connections 65535 // 許可されるリンクの数

}

location ~ .*.(gif|jpg|jpeg| png|bmp|swf)$ { access_log off; ログの期限切れ 30 日を閉じる // ローカル キャッシュを実装するためにヘッダー ヘッダーを出力します。 30 日} location ~ .*.(js|css)$ { access_log off;ログの有効期限は 1 時間です。 } ===== ===============毎


{


access_log off;ログをオフにする

expires 30d;//expires ディレクティブを介してヘッダーヘッダーを出力し、30 日間のローカルキャッシュを実装します

}

location ~ .*.(js|css )$

{

access_log off;ログをオフにする

有効期限は 1 時間;

}

===================== nginx ログスクリプトを毎日定期的にカットします

vim /usr/local/webserver/nginx/sbin/cut_nginx_log.sh
#!/bin/bash
# このスクリプトは00:00に実行されます

# Nginxログパス
logs_path ="/usr/local/webserver/nginx/logs/";

mkdir -p ${logs_path}$(date -d "昨日" + "%Y")/$(date -d "昨日" + "%m")/#p#ページングタイトル#e#
mv ${logs_path}access.log ${logs_path}$(date -d "昨日" + "%Y")/$(date -d "昨日" + "%m")/access_$(date -d "昨日" + "%Y%m%d").log
kill -USR1 'cat /usr/local/webserver/nginx/nginx.pid'



chown -R www:wwwcut_nginx_log.sh
chmod +x Cut_nginx_log.sh


crontab -e
00 * * * /bin/bash /usr/local/webserver/nginx /sbin/cut_nginx_log.sh


#/sbin/service crond restart

－－－－－－－－－－－－nginxの設定 gzip圧縮

通常の状況では、圧縮された html、css、js、php、jhtml およびその他のファイルのサイズは、元のサイズの 25% まで削減できます。つまり、元の 100k の html は圧縮後に 25k しか残りません。これにより、間違いなく帯域幅が大幅に節約され、サーバーの負荷も軽減されます。
nginx での gzip の設定は比較的簡単です

通常の状況では、次の設定行を nginx.conf の http セクションに追加するだけです

引用
gzip オン;
gzip_min_length 1000;
gzip_buffers 4 8k;
gzip_types text/plain application/x-javascript text/css text/html application/xml;

nginxを再起動します
Web ページの gzip 検出ツールを使用して、Web ページで gzip が有効になっているかどうかを検出できます
http://gzip.zzbaike.com/

---------------nginx エラーページをリダイレクトする方法

エラーページ 404 /404.html;

この 404.html は、nginx ホーム ディレクトリの下の html ディレクトリにあることが保証されています。404 エラーが発生した後に別のアドレスに直接ジャンプする必要がある場合は、次のように直接設定できます。

error_page 404 http://bbs.it-home.org/ ;


一般的な 403、500 およびその他のエラーも同じ方法で定義できます。 #p#ページングタイトル#e#


404.html ファイルのページ サイズは 512k を超える必要があることに特に注意してください。512k を超えないと、IE ブラウザのデフォルトのエラー ページに置き換えられます。

----------------------------------仮想ホスト構成

 Listen 80;
 server_name localhost;

 access_log /var/log/nginx/localhost.access.log;


 location / {

 root /var/www/nginx-default;

 インデックスindex.phpindex.htmlインデックス。 htm;
  }


 location /doc {

 root /usr/share;

 autoindex on;

 127.0.0.1 を許可;

 すべて拒否 }


 location /image
  ” root ” /usr /share;


 s s ‐ ‐ ‐ ‐ fastcgi_param スクリプトファイル名 /var/www/nginx-default$fastcgi_script_name; ️インクリメンタル f.localhost.com;

 access_log /var/log/nginx/localhost. access.log;

 root /var/www/nginx-default/コンソール;

 インデックス インデックス.phpindex.htmlindex.htm; } 場所 /doc { root /usr/share を許可します; } 場所 /usr/share ; $ { fastcgi_pass 127.0.0.1:9000; fastcgi_indexindex.p

#p#page title# e#


 }


 location /doc {

 root /usr/share;

 autoindex on;

 127.0.0.1; ‐ ‐ デフォルトの ‐ ‐ t‐、/etc/nginx/fastcgi_params を含めます。------------------------モニタリング

location ~ ^/NginxStatus/ {

stub_status オン; #Nginx ステータス監視設定 
}



このようにして、http://localhost/NginxStatus/ を通じて Nginx の実行情報を監視できます (最後の / は削除できません): 


アクティブな接続: 1
サーバーは処理されたリクエストを受け入れます
1 5
読み取り中: 0 書き込み中: 1 待機中: 0



NginxStatus で表示される内容は次のとおりです: #p#Paging title#e#

アクティブな接続 – 現在 Nginx によって処理されているアクティブな接続の数。 
サーバーは処理されたリクエストを受け入れる -- 合計 14553819 個の接続が処理され、14553819 個のハンドシェイクが正常に作成され (途中で障害がなかったことを証明)、合計 19239266 個のリクエストが処理されました (ハンドシェイクごとに平均 1.3 個のデータ リクエストが処理されました) ）。 
読み取り -- nginx がクライアントから読み取るヘッダー情報の数。 
書き込み -- nginx がクライアントに返すヘッダー情報の数。 
待機中 -- キープアライブがオンになっている場合、この値はアクティブ - (読み取り + 書き込み) に等しくなります。これは、Nginx が次の要求コマンドを待っている常駐接続の処理を終了したことを意味します。 


----------------------------------静的ファイル処理

正規表現を通じて、Nginx にさまざまな静的ファイルを識別させることができます


場所 ~ .(htm|html|gif|jpg|jpeg|png|bmp|ico|css|js|txt)$ {

root /var/www/nginx-default/html;
access_log off;
有効期限は 24 時間です;
}

画像、静的 HTML ファイル、js スクリプト ファイル、css スタイル ファイルなどについては、Nginx がそれらを直接処理してブラウザーに返すことで、Web ブラウジングを大幅に高速化できることを期待しています。したがって、このタイプのファイルの場合は、root ディレクティブを使用してファイルのストレージ パスを指定する必要があります。同時に、このタイプのファイルは頻繁に変更されないため、expires ディレクティブを使用してファイルのキャッシュを制御します。ブラウザを使用して不要なリクエストを削減します。 Expires ディレクティブは、HTTP 応答の "Expires" ヘッダーと "Cache-Control" ヘッダー (ページ キャッシュを制御します) を制御できます。たとえば、次の形式を使用して Expires を記述することができます: 

有効期限は 1970 年 1 月 1 日、00:00:01 GMT;
有効期限は 60 秒です;
有効期限は 30 分です;
有効期限は 24 時間です;
有効期限は 1 日です;
有効期限は最大です;
有効期限が切れます;

このように、 http://192.168.200.100/1.html と入力すると、自動的に var/www/nginx-default/html/1.html にジャンプします

たとえば、画像パスの下のすべてのリクエストは次のように記述できます: 

 #p#ページングタイトル#e#

場所 ~ ^/画像/ {
root /opt/webapp/images;
}


------------------------動的ページリクエスト処理【クラスター】

Nginx 自体は、JSP、ASP、PHP、PERL などの一般的な動的ページをサポートしていませんが、Tomcat、Apache、IIS などのリバース プロキシを介してバックエンド サーバーにリクエストを送信して、リクエストを完了することができます。動的ページの処理。前の構成例では、最初にいくつかの静的ファイル リクエストが Nginx によって直接処理されるように定義し、その後、他のすべてのリクエストが proxy_pass ディレクティブを通じてバックエンド サーバー (上の例では Tomcat) に送信されました。最も単純な proxy_pass の使用法は次のとおりです: 
location / { proxy_pass http://localhost:8080;

proxy_pass http://localhost:8080;
proxy_set_header X-Real-IP $remote_addr;
}





ここではクラスターを使用せず、ポート 8080 で実行されている Tomcat サービスにリクエストを直接送信し、JSP やサーブレットのようなリクエスト処理を完了します。 

ページの訪問数が非常に多い場合、複数のアプリケーション サーバーが共同で動的ページの実行を実行する必要があることがよくあります。このとき、クラスター アーキテクチャを使用する必要があります。 Nginx は、upstream ディレクティブを使用してサーバー クラスターを定義します。上記の完全な例では、tomcats という名前のクラスターを定義しました。このクラスターには 3 つのサーバーと合計 6 つの Tomcat サービスが含まれています。 proxy_pass 命令は次のように記述されます: 


# クラスター内のすべてのバックエンドサーバーの構成情報
上流の雄猫 {
サーバー 192.168.0.11:8080 重み = 10;
サーバー 192.168.0.11:8081 重み = 10;
サーバー 192.168.0.12:8080 重み = 10;
サーバー 192.168.0.12:8081 重み = 10;
サーバー 192.168.0.13:8080 重み = 10;
サーバー 192.168.0.13:8081 重み=10;#p#ページングタイトル#e#
}
場所 / {proxy_pass http://tomcats;# リバースプロキシ 
proxy.conf を含める;
}

------------------------ストレステスト
wget http://bbs.it-home.org//soft/linux/webbench/webbench-1.5.tar.gz
tar zxvf webbench-1.5.tar.gz
cd webbench-1.5
make && make install

#webbench -c 100 -t 10 http://192.168.200.100/info.php

パラメータの説明: -c は同時実行数を表し、-t は期間 (秒) を表します。 )

root@ubuntu-desktop:/etc/nginx/sites-available# webbench -c 100 -t 10 http://192.168.200.100/info.php
Webbench - シンプル Web ベンチマーク 1.5
著作権 ( c) Radim Kolar 1997-2004、GPL オープン ソース ソフトウェア。

ベンチマーク: GET http://192.168.200.100/info.php
clients、実行 10 秒

速度 = 19032 ページ/分、 18074373 tes /sec.
リクエスト: 3172 成功、0 失敗。

--------------PPC は、nginx の詳細な構成手順を提供します

#Running user
userEveryone;
#Start process
worker_processes 2;#p #ページタイトル#e#
#グローバルエラーログとPIDファイル
error_log logs/error.log Notice;
pid logs/nginx.pid;
#動作モードと最大接続数
イベント{epollを使用します。
worker_connections 1024;}#http サーバーを設定し、そのリバース プロキシ機能を使用して負荷分散サポートを提供します


http{#設定 MIME タイプ c include conf/mime.types
 default_type application/octet -stream; ; E_LOCAL] '' "$ Request" $ Status $ bytes_sent ''"$http_referer" "$http_user_agent" ''"$gzip_ratio"';
 log_format download'$remote_addr - $remote_user [$time_local] ''"$request " $status $bytes_sent ''"$http_referer" $http_user_agent" '"$http_range" "$sent_http_content_range"'; P gzip_buffers 4 8K;
 gzip_types text/plain;  出力バッファ 1 32K;
 Postpone_output 1460;
 Access_log ログ/アクセス ログ Main; m Client_header_timeout 3M ;
 SendFile on; cp_nopush オン
 tcp_nody オン; keepalive_timeout 65;
#負荷分散サーバーリストの設定 pupstream mysvr {#Weigth パラメーターは重みを表し、重みが大きいほど、割り当てられる可能性が高くなります。 8.3:80 重み = 6;
}
#仮想ホスト
 サーバーを設定します {Listen 80;Server_name 192.168.8.1 www.okpython.com;

 Charset gb2312;

#この仮想ホストの訪問ログを設定します

 access_log Logs/www.yejr.com.access.log

#訪問した場合/ /*、/js/*、/css/* リソースを管理し、squid を経由せずにローカル ファイルを直接フェッチします.

 root/data3/html;

 有効期限は 24 時間;

} # -to -/ローカルの負荷分散を有効にする http://proxy_set_header Host $Host ; proxy_set_header X-Real-IP $remote_addr; ' '' ‐ ‐ ‐ off;b proxy_buffers_size 64k;識別できます
 }
}

 コードをコピーします