バリバリチューニングしてパフォーマンスあげようぜ!というイベント
チューニンガソン2に行って来ました。
今回はn0tsさんとペアで参加してきました。(n0tsさんの記事はこちら)
結果は9位と何とか10位以内に入りとても嬉しかった反面、
幾つか遣り残したことあってもうちょい時間があれば!というのもありました。
時系列的にこんなことやってました
速度はメモってないのでアレですが・・・
前日
いわなちゃん初めてのAWS
そもそも全く触ったことがないのはさすがにアレだろうと初めてインスタンスを作って見ました。
MBPにVistaを入れだす
今回はペアで参加ということで迷惑はかけられないとTwitter専用マシンであんまり慣れていないOSXだとダメと思い急きょbootcamp+Vistaを入れ始めました。
しかし最新のマシンだとWindows7しか対応してないらしくドライバーは入れたものの管理用のソフト?が入らず操作しづらく断念しました
Gree Fast Processorの検証を始める
前回がWordpressでのコメントの書き込みかなんかだったので今回もきっとGETというよりPOSTなんだろうと(なぜか)おもって
PHPの速度大事そうだよねってことで、ソースの修正なしでなんとかGree Fast Processorを適用できないかと検討し出しました。
auto_prepend_fileとauto_append_fileを上手く使ってできないかとごにょごにょしてたんですが思った以上に厄介
かつ当日のプログラムによっては適用できないリスクが大きそうてことで中断
phcも試そうと思ったのですがいい加減眠かったのでここで諦め
当日
VarnishとTrafficServerをコンパイルしだす
課題がwikipediaミラーのGETだったためまずはVarnish3をインストールをしたところで
多分測定前に再起動されそうだなということでTrafficServer3もコンパイル
ここで考えていたのが1割キャッシュ出来れば・・・と思ったのですが
ページ数が多く想像以上にPHPを通した時の重く(一発1秒over)
途中でキャッシュ飛んだりなど失敗した場合リスクが高いと判断してキャッシュ戦略は放棄しました。
この時考えていたチートが全く別マシンで同じ環境作ってTrafficServerのキャッシュファイルを作成まるごとコピって置いておくだったんですが
流石にこれはNGだろうと考えこれもやめました。
なんでそもそも重いんだろう?とSQLを眺めてみる
とりあえず流れてるSQLでも眺めようとクエリログを出力してみたら結構すごい量流れていることが判明
インデックス貼ったりできないかなと見てたんですがこれは効くというのが思いつかず
とりあえず使っているテーブルからウォームアップ用のSQLを作成
このときMySQLが5.1.52なのにInnodb-pluginじゃないのに気づく
REMIから入れようとしたのですが依存関係で上手く入らず涙目でビルドすることに
懇親会二次会の時に聞いたのですがEL5じゃなくてEL6のREMIだったらよかったそうです。
見分け方教えてもらったので次からは・・・
SRPMからMySQL5.1.52のpluginを有効にしたRPMを作成して突っ込む
焦ってたのか上手くプラグインが有効にならずに少しタイムロスしましたが入りました。
PHP5.4β0をn0tsさんが作ってくれた!
これなかったら死んでました。
設定のチューニング
mysqlの設定はn0tsさんが、php.iniは僕、apacheはほんの少しだけいじった感じです。
mysqlは信頼性?なにそれおいしいの?ということでinnodb_flush_log_at_trx_commitを0にしたりと
本番だと余りやらないような設定をしていたと思います。メモっときゃよかった
php.iniは不必要なextensionを外したりあんま影響なさ気だったけどrealpath_cache_ttlとかいじってました。
apacheはそもそも2多重/台なのでリミットを絞ったりとかそこらへんです。
後は出そうなログは全部切りました
構成自体はAPP/DBを分けることなく同居でやりました。
何故か遅いインスタンス
作業はn0tsさんのインスタンスで行なっていたのですが同じ設定を突っ込んでいるはずなのに方系だけ
getするとほぼ1秒遅いという涙目な現象が・・・
いろいろ調べているのですが時間もないため僕のインスタンスの方にinnodb-pluginとAPCだけ(PHP5.1)を突っ込んでそれで提出しようとしました
しかし僕とn0tsさんのAZが違うということでしょうがなく両方共n0tsさんのインスタンスで提出となりました。
終了
測定の間はなんで方系だけ遅かったんだろうとn0tsさんと話してました。
だいたいこんな感じだったと思います
個人的にミスった・ここをやりたかったのがあったので書いときます。
こんなことやりたかった
パーティショニングをやりたかった
データも多いので、もしかしたらパーティショニングが有効だったかも・・・
後半じゃなくて前半に思い至ってれば有りだったかも
なぜMYSQL5.1.52を使ったし
5.5のほうがパフォーマンス良かったはずなのになぜか5.1をそのまま使ってしまった
キャッシュしたかった
今回1位の方がキャッシュを行っていたというのもそうなのですが
このように重いプログラムの場合そもそもPHPなどに処理させると負けなのでキャッシュは非常に有効です
もしかしたら遅い方のインスタンスはクエリログだしっぱなしだったかも
設定コピーしたはずなので無いはずなんですが・・・確認しようにも真相は闇の中
焦ったら負け
後半上手くプラグインやAPCが有効にならなかったりと焦ってました。
他の入賞者のコメントでそもそもmediawikiのチューニングポイントが公開されていたと聞いて少し後悔w
焦ると大きな視点で見えなくなってしまうのでアレですね次回以降の反省です。
最後に
今回会場はECナビのVOYAGEさんだったのですが本当にすごかったです。
執務室も見てみたかったです。
また、今まで家にXen鯖立ててるという理由でAWS触ってなかったんですが、
これからいろいろ触ってみて勉強しようかと考えています。
そして技評さんの記事を楽しみにしています。
スポンサー・運営の方々このような素晴らしいイベントを開いていただき本当にありがとうございました!
次回もあれば参加したいと考えています。
そしてペアのn0tsさん
本当にお疲れ様でした。そしてありがとうございました!
ペアじゃなかったら測定不能だったかも・・・
——
masudaKさんが事前情報(from mikeda)ほどチャラくなかったのが印象的でした。
ネタにして本当にすいません
[…] 第2弾!いろいろチューニングしてパフォーマンスを競うバトルイベント開催!「Tuningathon」2!! #tuningathon on Zusaar に @xcir こといわなちゃんとチームで参戦してきました。 すでに @xcir こといわなちゃんのブログに詳細なまとめがありますが、僕といわなちゃんがそれぞれ行ったことをまとめておきます。 […]