|
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 // 許可されるリンクの数 }
===================== nginx ログスクリプトを毎日定期的にカットします
通常の状況では、圧縮された 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 ブラウザのデフォルトのエラー ページに置き換えられます。 ----------------------------------仮想ホスト構成
|
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
