blogこの広告は、90日以上更新していないブログに表示しています。#2へ参加してきましたisucon前回非常に楽しかったので、今回も参加したいなーと思っていたのですが、「くらげとみかん」チームで、なんとか参加できました。走り書きだけど、考えたこと、やったことをメモっておく(あとでまとめなおすかもしれない)まずは最初に全サーバーへsshの鍵を通して、screenで全サーバーへログインした。前回ベンチマークを走らせるのが遅かった、という反省があったので、まずベンチマークを実行した。appをいじるための環境を整備した。reposを作ったり。tableしたり、全テーブルの件数を把握して、stockテーブル以外は対した容量にならない、ということを把握した。long_query_timeを0にして、ベンチを走らせて、全クエリをslowログへ出力し、mysqldumpslowで解析した。(この時点でpt-query-digest使っておけばよかった...)前回は、ボトルネック以外のところへ時間を消費してしまった、という反省があったので、stockテーブルへ注力してチューニングを始めた。チケットの席を発行する処理がぱっとみ遅そうだ、ということで、mysqldのINSERTまわりの設定をチューニング。具体的には、innodb_flush_log_at_trx_commitを0に。log-binを無効にしてみると少しスコアがあがった。null;してseat_idのデータを減らす。rand"しているクエリがあったので、とりあえずオフにしてベンチしてみたら通ったので、そのままにした。ROW_FORMAT=Compressedしてみたら少しあがった。mysqldumpslowが見づらいので、やっぱりpt-query-digestを落としてきて実行する。NULL"のクエリが重いので、そこをなんとかしてなくせないかなーと考えていたら、updated_atと同じ容量で、order_requestへ移せばいいんじゃね?と思ったので、アプリケーションを安全に保ちつつ、徐々に移行していった。具体的には、variation_id/seat_idをorder_requestへ追加して、二重にINSERTするようにした。次はJOINしまくっているクエリで、stockテーブルを使っていたところをカラムを追加したことでorder_requestを代用できるようになったのでとても高速になった。queryを取得し、pt-query-digestを実行し、アプリを書きかえては、ベンチを実行して測る、というのを繰り返したfor文の中で、1クエリ実行している箇所があったため、INを使ったクエリへ書きかえた。売りあげたチケット数、で算出する、という方式に変更。(17:45)ここまででタイムアップしました。235274)はけっこうよかったようです。カウンタテーブルを用意したことで、購入処理は重くなったが、その一方でチケット残数表示は早くなったんじゃないかと思います。UPDATEとロックの挙動kamipoさんが補足を書いてくれたので、参照するとよいです。(1)はてなブログをはじめよう!walf443さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。