#isucon に参加してやったこと思ったこと - かみぽわーる
ISUCONに@riywoと「チームやすべえ」で参加してきたので、その感想です。 ひと言でいうと、良くも悪くもみんな積み重ねてきたものが結果に出たのではないかなと思います。 最初のボトルネックとして用意されていたクソクエリのチューニングは、二人ともDB寄りのエンジニアということもあって、クエリの意図をつかんだあとの対策はツーカーでいい感じでした。 ボトルネックがアプリに寄ってコア数でスケールする状態になったので、コア数も多く経路的にも有利なrevとdbにもアプリを立てて、そっちに多くのリクエストを振るようにしました。細かいチューニングを省略すると、これだけやっただけで、たしか参加チームの中で最初に50000req/minを超えたと思います。 あとは後半、かなり良いスコアを出すチームがちらほら出てきて、このアーキテクチャだと優勝できないと気づいて、キャッシュしてDBアクセスとレンダリングのコ
#isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、
チート対策とhttp_loadに仕掛けた罠の話 #isucon - blog.nomadscafe.jp
完全に文化祭疲れで昼寝3時間ぐらいしてしまいましたが、懇親会で聞かせて頂いた話やblogやtwitterをみる限り好評だったようで、うれしく思っています。ISUCONに参加して頂いた方、社内で協力して頂いた方ありがとうございました いくつか至らぬ点がありますが、明日以降に公式にフォローさせて頂きたいと思っています。 さて、既に公開されているので見た方は多いと思いますが、今回ISUCONで使ったベンチマークツールは大きく分けて次の3つのツールに分かれています。 (1) 1post/secでコメントを投稿し、1秒後にコメントをしたページと、インデックスおよび適当な記事のDOMチェックを行う node.js (2) http_load + patch (3) css/js/imageのMD5値を検証する perl script 最終的な順位はhttp_loadが行ったリクエスト数で決まるのでもし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
