もう1週間もたっちゃいましたが・・・
『いろいろチューニングしてパフォーマンスを競うバトルイベント!Tuningathon2』に@masudaKさんとペアで参加してきました。
(@masudaKさんのレポートはこちら)
結果は7位!!!
当日の様子はECナビさんの広報ブログにのってます
http://pr.zero-start.jp/archives/65617435.html
なんとなく印象に残ってるのはこのへん
- まさかのCPUバウンド(キャッシング、MySQLのクエリ改善あたりの戦いかと思ってた)、まさかの秒間2-3リクエストの戦い
- AJITOでみんなでビールのんだ!
- イカセンター行ってきた!(イカいなかった・・・)
- いわなちゃんに勝った!!!
楽しくて、勉強になって、そしてすんごく疲れました・・・
イカ、うろ覚えながら
当日の回想
ルール
mediawikiのアクセスをどこまで高速化できるか
- Wikipediaのデータが入ったEC2が2台渡される。使い方は自由
- mediawiki自体(プログラム)はいじっちゃダメ
- DBのデータはいじっちゃダメ
- 測定はhttp_loadを使う。アクセスは記事ページのみ
という条件で始まりました
まずは、なにはともあれ
構成検討
役割を分けるメリットがなさそうなので、全く同じWEB/DB構成を2台並べることに決定
当初はアクセスが2並列だという話だったので片側が遊んでる状況がないように
- LVSでコネクション数みて振り分けるか
- APPサーバのコネクション数を1に絞って、nginx使ってアクセス中だったら別サーバから再取得させる
など考えたのですが、運営側から「4並列に変更します」と発表があったので検討ヤメ
チューニング開始
まずは手分けして当たり前で効果の高い必須チューニングをやります
秒間数アクセスレベルなので、ネットワーク系のチューニング(カーネルパラメータ等)は無視しました
合わせてhttp_loadも導入、テスト用のURLを作成
PHPチューニング
まずはどういう処置が重いのかを確認したかったのでxdebugを入れてみてみます
・・・見なかったことにしよう
時間のかかる処理がいくつかのブロックに分かれていて、数百、数千レベルの関数コールがいっぱい。
解析してどうこうは諦めてとにかくPHP自体の高速化を目指すことにしました
というわけで方針は
に絞りました
経験のある@masudaKさんにPHP5.4のコンパイル作業をまかせて自分は(*゜ρ゜)ボーっとする
コンパイル完了!(OSが想定外の32bits版だったのでいろいろハマってたみたいです)
/root/local/にインストールされてるwww
気にせずFastCGIプロセスとnginxを起動したらなんとなく見れました
http_loadを走らせてみます
すんごい速い!!!
と思ったら全部リダイレクトされてるwwww
ログを確認したところ
http://
のリライトが効かなくなってるらしい
@masudaKさんがもう1台のPHPコンパイルしてる間にリライト設定をいじります。
テストURLは「http://
メモってなかったので記憶ベースですがたぶんこんな感じ・・・
server { listen 80; server_name wiki.example.com; root /var/www/html/mediawiki; location / { index index.php; error_page 404 = @mediawiki; } location @mediawiki { rewrite ^/(.*) /mediawiki/index.php?title=$1 last; } location ~ \.php?$ { include /etc/nginx/fastcgi_params; fastcgi_pass 127.0.0.1:8000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }
もう1台のPHPコンパイルも完了し、ここでいったん目標達成!!!
PHP入れなおしたときにAPC入れ忘れてることに気づきましたが、残り10分だったので諦めます(ここはちょっと心残り)
直前で最後のテストを走らせてみます
[ec2-user@host79 data]$ http_load -rate 4 -fetches 100 top1000_all.list http://175.41.238.74/mediawiki/index.php/中原れい: byte count wrong 100 fetches, 12 max parallel, 7.87196e+06 bytes, in 25.8125 seconds 78719.6 mean bytes/connection 3.8741 fetches/sec, 304967 bytes/sec msecs/connect: 2.02277 mean, 56.073 max, 0.428 min msecs/first-response: 1507.51 mean, 11558.5 max, 230.309 min 1 bad byte counts HTTP response codes: code 200 -- 93 code 404 -- 7
テストケースの問題で7件の404が出てるのですが、それでも3.8はけっこういいのでは!!!
byte count wrongがなぜか出ていて、この点は結果発表時にも指摘されたのですが原因はよくわかりませんw
タイムアップ!!!
疲れたー