cacheを効かせるのが王道です。Cacheプラグインを利用してなるべくPHPやMySQLにアクセスさせないようにすると、手軽で絶大なパフォーマンスアップが可能です。今回はそこからもう一歩進めたチューニングについて書きたいと思います。二段階層を廃したシンプルな構成まずは、図をご覧ください。前述の王道チューニングの構成はA図となります。cacheはNginxがバックエンドのサーバーに処理を回し、返ってきたレスポンスをキャッシュして、Nginx自身がキャッシュを返すことでパフォーマンスを上げる仕組みです。A図-1がキャッシュの無いアクセス、A図-2がキャッシュが効いているアクセスを表しています。jpgなど)をフロントのNginxが直接返すことを表しています。cache自体はバックエンドのサーバーがHTTPでコンテンツを返してくれれば、どんなアプリケーションでも問わない汎用的なキャッシュ機能です。cacheを利用しようとするともうひとつHTTPサーバーが必要になり、A図のようにHTTPのレイヤーが二段構成になります。cacheという機能(HttpFcgiModule)があります。これはバックエンドのFastCGIのレスポンスをキャッシュする機能です。cacheを利用したのと同じ効果をHTTPサーバーなしに実現できます。A図の8080ポートのサーバーが必要なくなり、B図の構成になります。無駄な通信と処理がなくなり、シンプルです。Cacheは、アクセスごとに動的に生成される記事を、静的なHTMLファイルとして保存(キャッシュ)して、それを返すように振舞うプラグインです。キャッシュが効いている間はMySQLにアクセスすることが無いのでパフォーマンスが上がります。Cacheを利用すると、.htaccessに以下の設定が追加されます。Cacheによって静的なファイルが生成されている場合、PHPを介さずにApacheが直接リクエストを返すようにする設定です。Cacheの推奨設定では、index.htmlとそれを圧縮したindex.html.gzが用意されるので、冗長な設定になっています。Cacheは本来のパフォーマンスを発揮しません。cacheに到達することもなく、静的ファイルと同じ処理、パフォーマンスになります。HttpGzipStaticModuleNginxのHttpGzipStaticModuleは、同じディレクトリ内にあらかじめ圧縮ファイル(.gz)が用意されている場合に、クライアント判定を行なって自動的に圧縮ファイルを返してくれるモジュールです。(正確には、Gzip圧縮に対応しているクライアントからリクエストが来て、同ディレクトリに同タイムスタンプで同名+.gzという名前のファイルがある場合)このモジュールを導入するメリットは、gzファイル分の.htaccessを移植する手間がなくなることです。コアモジュールではないので、コンパイル時にオプションで指定する必要があります。--with-http_gzip_static_moduleコンパイルし直したnginxの入れ替えを行う場合は、こちらを参考にしてください。リクエストを落とさずにnginxをアップグレードする方法とその検証NginxにはコアモジュールでHttpGzipModuleがあり、設定をオンにすることで特定のContent-TypeにGzip圧縮をかけてレスポンスを返すことができます。こちらはリクエストごとにオンザフライで圧縮をかけるので、余分に処理がかかります。cssやjsなどの圧縮ファイルが用意できる場合は、同階層に設置してHttpGzipStaticModuleの恩恵を受けたほうがいいと思います。サンプル設定ファイル前述の項目を網羅して、かつ可能な限り正常に動いている環境の設定ファイルを載せています。これが最も安全だと思います。/”ディレクティブを通ります。(記述順番は関係ありません。)静的ファイルのチェックこのディレクティブの先頭でリクエストされた静的ファイルが存在するかのチェックを行なっています。/”ディレクティブの処理が終わります。次に、マッチするlocationディレクティブがあればそちらが実行されます。\.(css|js)$”ディレクティブへ処理が続いていきます。これがB図-3の流れです。cacheのチェック静的ファイルとして存在しなかった場合、処理は下へ進みます。Cacheが生成したキャッシュファイルの存在をチェックし、キャッシュファイルを利用するかどうかを下に続く条件で確認していきます。cacheを利用するかどうかのチェックも行なっています。\.phpディレクティブで利用されます)。/wp-content/cache/supercache/${http_host}${uri}/index\.html(\.gz)?$”ディレクティブへ処理が続きます。これがB図-4の流れです。\.php”ディレクティブへ処理が続きます。cacheが使われ(B図-2)、キャッシュがなかったり、期限が切れていた場合は、FastCGI(PHP)へ処理が渡されます(B図-1)。今回はステータスコード200の時は10分、404の時は1分キャッシュするように設定してあります。Foundは無視できないくらい重い処理です。404に対してキャッシュが作られないと、存在しない記事にアクセスがくる度にPHPとMySQLが仕事をしてしまいます。付けてレスポンスを返すことがわかりました。cacheはキャッシュを作らないようなのです。スマートな方法があると思いますが、今回はWordPressのソースを少しいじって対応することにしました。}}これで404もキャッシュされるようになりました。Tokyoに微力ながらスポンサーとして協力させて頂きました。ブログにもWordPressの記事が少なく、弊社がWordPressにコミットしている感じが伝わっていないと思ったので、開催前に何とか間に合って良かったです。下記サイトを参考にしてください。Cacheという機能がある。これは名前の通りCGIの処理結果をキャッシュするものである。Apacheよりも負荷に強く、軽量なNginxでWordpressを当サイトを運用しています。Cache』のプラグインを導入しました。Nginxを使ったもう一歩進んだWordPressチューニングを参考に設定しました。書いてあって、最初は辛そうに感じましたが、案外あっさりと設定できました。FastCGIではなくPHP-FPMを選んだのはNginxを使ったもう一歩進んだWordPressチューニングという記事を見たからです。FastCGIではなくPHP-FPMを選んだのはNginxを使ったもう一歩進んだWordPressチューニングという記事を見たからです。原因はコピペしただけで済ませたconfであるのは判明しているのですが(※参考サイトの情報に間違いがあるワケではありません)、どこをどう弄っていいのやら。FastCGIではなくPHP-FPMを選んだのはNginxを使ったもう一歩進んだWordPressチューニングという記事を見たからです。Nginxを使ったもう一歩進んだWordPressチューニングを参考にしました。そこの設定ファイルは、マルチサイト用じゃないけど。14:08:参考として性能比較が欲しいです!後、コメントしようとしたらopenidベースのコメントは404エラーになりました。[...]コメントを残す(通常のコメント欄に切り換え)返信をキャンセルする。名前アカウントを持っているサービスをクリックしてください。cloudropcloudropは、クラウドコンピューティングを利用したサービスの提供・インターネットサービスの技術支援を行う会社です。