Nginxを使ったもう一歩進んだWordPressチューニング
Nginxを使ったWordPressのチューニングといえば、フロントエンドのNginxとバックエンドのNginx（もしくはApache）に分けてproxy cacheを効かせるのが王道です。 さらにWP Super Cacheプラグインを利用してなるべくPHPやMySQLにアクセスさせないようにすると、手軽で絶大なパフォーマンスアップが可能です。 今回はそこからもう一歩進めたチューニングについて書きたいと思います。 二段階層を廃したシンプルな構成 まずは、図をご覧ください。 前述の王道チューニングの構成はA図となります。 proxy cacheはNginxがバックエンドのサーバーに処理を回し、返ってきたレスポンスをキャッシュして、Nginx自身がキャッシュを返すことでパフォーマンスを上げる仕組みです。 A図-1がキャッシュの無いアクセス、A図-2がキャッシュが効いているアクセスを表していま
nginxがApacheよりも優れていることが一目瞭然のグラフ
前回のリプレイスでどのくらい変化があるかを調べてみました。構成などはそちらをご覧ください。 対象サーバーをDNSから外してアクセスを止め、リプレイス作業後、DNSに再登録しました。 そのビフォアとアフターのグラフです。 Apacheのアクセス数 横軸のひと目盛は6時間なので、4日午前0時にアクセスが止まって、5日の午前2時にアクセスがもどっていることがわかると思います。（3日のアクセス数が少ないのはラウンドロビン環境下のサーバーを2台から3台に増やしたからです。5日には再び2台に戻しています。） nginxのリクエスト数（アクセス数） nginxも5日の午前2時頃からアクセスされ始めました。ビフォア（Apache）もアフター（nginx）もちょうどピーク時に160リクエスト程度を受けているので、アクセス数は同じくらいと考えられます。 トラフィック ビフォアとアフターでピーク時に2Mbits
Apacheをnginxにリプレイスした
yubitterという携帯向けTwitterクライアントサービスで、ユーザーのアイコンを携帯電話向けに変換している(※1)、いわゆる画像変換サーバーのhttpd部分をApacheからnginxへ変更しました。 処理は単純に以下の流れです。 クライアントからアイコン画像のリクエストが来る 既にハードディスクにキャッシュファイルがある場合は、それをそのまま返す ファイルがない場合は、PHPプログラムがアイコン画像がアップロードされているTwitterのサーバー（現在はAmazon S3/CloudFront）へ取りに行く PHPプログラムが取得した画像データをGDライブラリを利用して加工、ハードディスクに保存、レスポンスを返す 変換するにあたり、以下の2パターンを検討しました。 リプレイス案1は、Apacheのレイヤーを一つ下げてAPサーバーに専念してもらう案で、2案は、Apache+mod_
Rackspace Cloud ServersがAmazon EC2よりも優れている点
Cloud Serversは、メモリ256MB/ディスク10GBのインスタンスから用意されていて、 このミニマムのインスタンスが$0.015/時間で借りることができます。1ヶ月利用で$10.8。 256MB以上のインスタンス、例えばメモリ1GB/ディスク40GBのインスタンスでも$0.06/時間。 ディスク容量がネックになる用途以外では魅力的なラインナップではないでしょうか。 特にテスト機や実験機として一時的に利用したいようなケースでは、ロースペック・ローコストはとても助かります。 自動バックアップサービスが無料 バックアップと言ってもデータ自体のバックアップではなく､LVMのスナップショットベースのバックアップになります。 ファイルを個別に取り出すことはできませんが、データを復元する上では全く問題ありません。 このスナップショットがインスタンスごとに3つまでストックできるようになっていて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
