1. ホーム /
  2. ご案内 /
  3. サイトのパフォーマンスアップ施策

サイトのパフォーマンスアップ施策

  • このエントリーをはてなブックマークに追加

WEBサイトのパフォーマンス向上を目指して様々な施策を試みてみました。

ヘッドライン

旧パフォーマンス

当サイトは、GMOクラウドのVPSサービスマイクロプランにPleskをオプションで追加しています。
安いサービスなので、パフォーマンスはこんなところだろう。。。
けど、もしかしたらこちらのチューニングで少しくらい改善しないだろうか?
と、おもい、勉強がてらチューニングしてみることにしました。

ほとんどのWEBサーバーの場合、デフォルト（標準設定・初期設定）のまま運用されており、それは、必ずしも現在運用中のWEBサイトに最適であるとは言えません。
そこで、ほんのすこしカスタマイズすることで同じようなことでも大幅にパフォーマンスが改善されます。
パフォーマンス改善は、WEBページの表示が早くなる事につながり、結果的に検索結果向上につながっていきます。
上記画像は初期設定の段階でのパフォーマンス。
FirstByteTimeがFというのは、かなりパフォーマンスが悪いと言える。
と、いうより、なにもしていないので、大量にアクセスを獲得したとしたら、さばききれなくなるのが目に見えている。
すこしづつかいぜんしていく。

WEBサーバーの変更

まず一番最初に手掛けたのはApacheWEBサーバーからnginxへの移行です。
なぜ、一番最初に手掛けたのかというと、Apacheでチューニングした後、やっぱりnginxにしたい！となったらチューニングももちろん一からやり直しになるからだ。
二度手間はごめんです。ということで、今回はnginx採用とすることとしてチューニングすることにした。
まず、上記のものは、Apache時代のもの。
nginxに変えたことで体感は少しばかり早くなった気がしていたが、変えただけでは状況はほぼ変わらずでした。

nginxにしたことで、面倒も発生

今までのApacheWEBサーバーなら、.htaccessが容易に使えたので、リライトルールなどをhtaccessに記載して、アドレスを静的ページに見せかけるという施策を打っていたが、nginxではhtaccessは使えない。
WordPressで静的ページは不可能なのか?と思っていたが、可能だった。
なので、ディレクティブ設定に静的ページ化に必要なリライトルールを1行追加。
この1行で、WordPressの出力するリライトルールはどんなものにも対応するようになった。

Apacheでも、htaccessを使わないようにする

htaccessは、Apacheの場合は、httpd.confや、その他の設定ファイルを読み込んだ後、アクセスごとにさらに設定を読み込む仕様だ。
なので、どんな状況であれ、毎回設定ファイルをロードして処理するようなものだ。
アクセスが大量に発生するようなケースまで成長していた場合、ほんのちょっとしたことだがhtaccessを読み込む負荷ももったいなくなる
本来は、htaccessに記載すべき事項も設定ファイルに記載したほうが良い。一口メモとして書いておく。

nginxで動作しない

nginxを導入して、トップページはnginxで動作するようになった。
しかし、末端ページになると、なぜかApacheで動作している感じだ。
なぜわかったのかというと、nginxにリライトルールを記述したうえで動作確認をしてみた。
当初、動作したと思って安心し、その後htaccessを削除すると、Apacheが、NotFound（404エラー）を出力した。
これは、リライトはhtaccessにしたがって、そして、htaccessを消したから、存在しないということになってしまった。ようはnginxに行っていないのだ。
このページのURLを見ていただければわかるが、.htmlと、HTMLファイルとして認識させたかったのだが、どうもこのあたりからおかしくなっている気がした。
なので、htmlではなく、/で終わるルールにしてみたら、これはnginxに行った上でリライトルールが動いた。htaccessが無くても静的アドレスになった。
ようは、.htmlという拡張子にするとApacheに行ってしまう。
なぜかと調べたら、nginxで動作させるファイルの拡張子を指定する欄があり、そこには、htmlおよびhtmが記載されていないので、nginxで動作させないファイルとなっていた。
すぐさま拡張子を記載して確認をしたところ、問題なくnginxで操作した。
これで、まずはWEBサーバーの移行は完了した。

nginx採用とgzip圧縮

その時点で確認したところ、少々パフォーマンスが改善した。
しかしながら、FirstByteTimeがCは、もう一歩改善したい。
道筋としては次はApacheではよくやるgzip圧縮設定だろう。
CompressTransferがFで、当サーバーは圧縮をかけていない。
アクセス解析用のjsファイルや、ブログ村の画像などは圧縮がかかっているので多少圧縮ファイルの存在は確認できるが、すべて外部のサーバー。
自前サーバーは0だった。
なので、すこし圧縮を掛けるべきだろうと思い調べてみると、Ａｐａｃｈｅ同様圧縮の設定はあり、ディレクティブに数行追加するだけであっさりできた。
圧縮設定はＡまで上がったが、それでもＦｉｒｓｔＢｙｔｅTimeは、Cのままだった。
もう少し何とかしたい。次に改善するとしたらCacheだろう。
キャッシュは、よく呼び出されるファイルなどをメモリにロードした状態にしておき、呼び出されたらすぐ処理するという利用方法で、メモリが潤沢にあるのであれば有効に使えるだろう。
ｎginxでキャッシュが動かせるので設定してみる。
しかし、反応しない。
知り合いで同じ仕様のサーバーでnginxでキャッシュをかけている方に聞いても設定ファイルは同じ状況、でもキャッシュがかかっている。私はかからない。。。
これは、もしかしたらWordPressの動的ファイルだからじゃないかと思った。
なので、WEBサーバーでキャッシュを持たせるのはちょっと厳しそうなので、WordPressでキャッシュを持たせることにした。
しかし、このCacheStatｃContentは、Fのままだ。WEBサーバーのキャッシュ機能とは違うので認識しないのではないか、と、同時に、動いていないことを疑った。

最終形態

動作改善

見ていただいてわかるように、FirstByteTimeがAになった。
これは、WordPressにキャッシュプラグインを導入する前まではCだったので、プラグインのキャッシュ機能は効いたのだろう。
ただ、CacheStaticContntには反映しないのが気に食わないが、これは、本来Aであろうと予測される。
CompressImagesをAにしたいところだが、小さいファイルなどいろいろあり、すべてを圧縮かけることは逆効果なので、ちょうどいい落としどころだろう。
ProgressiveJPEGｓｈ、プログレッシブJPEGがどれだけあるかというものだが、基本的には画像をプログレッシブで保存していないので（ファイルサイズが大きくなるから）特段気にしない。

同様に、CompressTranfer、要は全体のGzip圧縮の8割くらいが圧縮されている状態だが、小さいファイルは圧縮をかけるCPU負荷がノーマルのファイルサイズを超えてしまうのでちょうどいいあんばいだと思う。
先述のようにここに出てこないが、キャッシュも持っているので、これがちょうどいいと思われるパフォーマンスだ。

FからAへ

GMOクラウドのVPSサービスマイクロプランでもFirstByteTimeをAにすることができたのは素晴らしい。
まず、nginxにしたことでにしたことでかなり早くなった。
また、Plesk上で管理するのなら、各ドメイン、各サブドメインごとに、nginxの利用可否や詳細設定をいじれるので、コンテンツ内容などによって採用可否やディレクティブ設定を替えればよい。
パフォーマンスAのサイトと、Fのサイトが同居するような設定が可能だ。
Pleskは１１になってから、今まで以上に使い勝手がよくなり、特にある程度サーバーの設定をいじる人がコンパネ上から手軽に修正ができるようになったことと、ホストごとに設定できるので、違う環境が必要なホストを共存させることができるようになったのが大きい。
こんごもPleskをすすめたい。

最後の最後のパフォーマンスはここまで来ました。

最最終

現在一番のボトルネックはDNSサーバーです。
サブドメインの追加が頻繁で、現在はTTLを10分にしているから、もう少し落ち着いたら1～2日スパンにすることでもう少し改善できるだろう。
ただ、FirstByteがもはやAなのでそこまでやるかどうかはまた考えることにしよう。

SNSでもご購読できます。