こんにちは、はるたま在住、七森中調律部のれいさです。
なにやら面白いお祭りをやるらしいぞと紹介されたので、賞品とか目標も特に何も考えずに参加してみることにした。最近仕事でAzureを使うようになったので、ちょうど良いタイミングだったかも。
Azureを使うのは初めてではないので、無料体験期間とかそんなものは無かった。
余談。このブログはAzure Websites上でNodeアプリ(Ghost)として動いている。
1stステージのまとめ
とりあえずちょっと前に1stステージが終わったところ。気づいたら1stステージは暫定1位で終わっていた。→ 3位!!!11
1stステージは、Azure Websites上で動くWordPressをチューニングする内容だ。詳しいルールはここに書いてある。
Azure WebsitesはVMとは違い、従来のレンタルサーバーに近い感覚で、ウェブサイトやアプリを素早くデプロイできるプラットフォーム(PaaS)である。イメージ的にはだいたいHerokuに似ているが、安い上になんといってもMicrosoftなので信頼感が高い。このあいだ日本リージョンができたし、なんとNodeも動く。GitHubと連携もできる。神サービス。
今回のチューニングのテーマ
- ｼｭｯｼｭｯﾊﾟｯ (意訳= 非常に快適なブラウジング ・ レイテンシ小さめ)
やったこと
1. とりあえずチュートリアル通りに構築
この記事でWordPressを実際に動かす所までが解説されていた。ピュアなれいさは、特に変な事をしてスタートダッシュをキメようとか特に思う事も無く、これに従ってWordPressをインストールした。
インスタンスはSを1つ。PHPバージョンは5.5にしておいた。
2. プレーンな状態のパフォーマンスを計測
とりあえず、簡単に wget -m http://maniax/ で全ページの取得にかかる時間を今回のチューニングにおけるパフォーマンスの基準にした。
- 全ページ取得時間: 12分40秒
- 平均レイテンシ: 1400ms
たまげるほど遅い。なるほどこれはチューニングのしがいがある。
3. MySQL関連チューニング
経験上、WordPressで時間がかかってるのは大体がSQLクエリに関する処理なので、まずはそこから弄っていくことにした。
- DB Cache Reloaded Fix プラグイン
クエリをキャッシュする風に見えるコイツをインストールして、クエリを削減してみた。すると、体感で200msぐらい速くなった気がする。それでも超遅い。ページが表示される前にブラウザのタブを閉じるレベル。
そういえば、MySQLサーバー自体のパラメーターは弄れるのかな・・・と調べてみる。チュートリアル通りにWordPressを用意をすると、ClearDBというMySQL PaaSが自動的に使われるようで、ClearDB上に自動的にアカウントが作成され、関連づけられていた。
確認してみたところ、無料プランで契約されていた。プラン一覧はこちら。 さすがに無料プランだと、制限がかなりきついようで、
- 容量20MBまで
- 同時4コネクションまで
となっているため、コネクションプーリングしていない感じのWordPressから利用する感じだと死亡必至である。
月額$9.99のプランでは15コネクションまでいけるらしい。とりあえずこの時点での一番のボトルネックはココにあると思い、プランをアップグレードして様子を見てみた。黄色い背景色で強く推奨されているSaturnプランは月額$49.99と高額である。
- 全ページ取得時間: 5分30秒
- 平均レイテンシ: 638ms
パフォーマンスがだいたい2倍ぐらい良くなった。うんうん。よしそれじゃあ黄色い背景色で強く推奨されているSaturnプランにさらにアップグレードし…しない。高い。というわけで同じリージョンに仮想マシンを使ってMariaDBを構築。
- 全ページ取得時間: 4分
- 平均レイテンシ: 464ms
キャッシュ関連の設定を弄ってみたけど、誤差程度にしか変わらなかった。
4. WordPress設定チューニング
だいたい次のように変更した。
wp-config.phpにdefine('DISABLE_WP_CRON', 'true');を追加: ぽろぽろ発生する処理を無くす- Settings -> Reading から 1ページあたりに表示する投稿数を1に変更: 1ページあたりのレイテンシ高速化
- 全投稿のコメントを無効化
- 生成されるHTMLが軽いかつ、
functions.phpの重量が軽い(Edit Themeページ/wp-admin/theme-editor.phpで確認できる)テーマに変更
5. WP Super Cache を入れる
ここでやっと有名プラグインWP Super Cacheの登場です。
Permalink設定がデフォのままだと動作しないよと警告が出て使えないので、Permalink設定をデフォ以外に設定。すると設定画面が表示されて使えるようになる。
- 全ページ取得時間: 31秒
- 平均レイテンシ: 60ms
劇的に速くなった。
6. エラーログを分析する
しばらくして、あることに気がつく。
エラー率急上昇！なぜだろう。
というわけでログを見ることに。
このように、Azure Websitesの構成を変更する。(デフォはオフ)
しばらくして、FTPS等でログファイル確認するとそこには大量の302リダイレクトの嵐が。そう、今回のルールでは、300系レスポンスもエラー扱い。
この問題をなんとかしないと、勝利の栄光を掴めそうにない。
7. WP Super Cache をチューニング
ログをじっくり眺めた結果、チューニングマニアックス側から来ているアクセスは、/?p=67 のようなWPデフォのPermalinkを直接叩いていて、デフォ以外のPermalinkに設定した場合はリダイレクトされるような挙動になっているということが分かった。
そこで、Permalink設定をデフォに戻した上でWP Super Cacheを動かすことが出来ればいいんじゃないかと。
WP Super Cacheの設定ファイルやプラグインのソースを眺め、Permalinkの設定変更を強制する部分とデフォのPermalinkでキャッシュできるように挙動を本大会用に改善。
8. 仕上げ
余興に以下の設定も行った。まあほとんどデフォで最適化された値になっていて、弄れない。
- (php.ini)
opcache.validate_timestamps=Off- インスタンス再起動するまでオペコードキャッシュがリフレッシュされなくなるという過剰な設定 - (php.ini)
display_errors = Off- デバッグ時以外はオフ。
最終的に
- 全ページ取得時間: 15秒
- 平均レイテンシ: 30ms (6ms～)
こんな感じに。
9. エラー率を0にする
ログをみたところ、実はまだエラーが発生していた。404エラー。
/?p=7 こんな感じで投稿ID直にアクセスしてきて、存在しないのでエラーになっていた。これはオリジナルのIDを維持したままのインポートに失敗していて、他の空きIDに再割り当てされてしまった為に発生。
一度DBのテーブルを綺麗にお掃除して、再インポートすると直ってたりするが直ってない事もある。ちょっと謎。詳しくは調べてない。どうしても直らないときはDBを手直しする。
結果、エラー率が0に(少なくともサーバーログ上は)なった。
10. スケールアウト
実は、この時点で2位にまでランクアップしていたのだけど、1位との差がなかなか縮まらないというか。
なんかﾋﾞﾐｮｰに縮まってはいるんだけど、もうあとやることなかったのでAzureのクラウドパワーを信じてスケールアウトしてみた。
- S×1 → S×3
結果、クラウドパワーのおかげでスコアが3倍に。
ちゃんちゃん。
感想
仕事でなら何度もやったことある構築作業でも、こうして「競技」としてゲーム感覚でやってみると新鮮というか、ただ純粋に楽しいなって思った。
2ndステージはもう少し変わったアプローチをとってみたいな！