ISUCON予選突破を支えたオペレーション技術 - ゆううきブログ
ISUCONに参加する会社の同僚を応援するために、ISUCONの予選突破する上で必要なオペレーション技術を紹介します。 自分がISUCONに初出場したときに知りたかったことを意識して書いてみました。 一応、過去2回予選突破した経験があるので、それなりには参考になると思います。 といっても、中身は至って標準的な内容です。 特に、チームにオペレーションエンジニアがいない場合、役に立つと思います。 今年のISUCON6は開催間近で、まだ予選登録受付中です。 ※ 文中の設定ファイルなどはバージョンやその他の環境が異なると動かなかったりするので必ず検証してから使用してください。 ISUCONでやること (Goal) ISUCONでやることは、与えられたウェブアプリケーションをとにかく高速化することだけです。 高速化と一口に言っても、複数のゴールがあります。ウェブアプリケーションの場合は以下のようなも
ISUCON4 予選でアプリケーションを変更せずに予選通過ラインを突破するの術 - Hateburo: kazeburo hatenablog
AMIが公開されたのでもう一度やってみた。 AMIについてはこちらのエントリに書かれています ISUCON4 予選問題の解説と講評 ＆ AMIの公開 : ISUCON公式Blog まず ami-e3577fe2 を m3.xlargeで起動します。 CPUは model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz でした。 とりあえず、MySQLのindexを追加する。init.shに追加 $ cat init.sh cat <<'EOF' | mysql -h ${myhost} -P ${myport} -u ${myuser} ${mydb} alter table login_log add index ip (ip), add index user_id (user_id); EOF ベンチマークツールのhttp keepal
ISUCON4 予選で workload=5 で 88000点出す方法 (lily white 参戦記) : DSAS開発者の部屋
ISUCON4 予選1日目に、 lily white というチームで参戦してきました。 試合中に 62000 点は出していたのですが、最終的に提出したスコアは 60344 点でした。 以降、予選終了までと、その後に気づいたさらにスコアを上げる方法について書いていきます。 実際の提出時のコードは methane/isucon4q-go リポジトリの "final" タグを見てください。 準備 (~前日) 予選方式が発表された時点で、 isucon3 予選と同じ方式だったので、有効な作戦もほぼ同じになる事が予測できました。 具体的には以下のとおりです。 PIOPS な EBS を使わないので、性能が不安定なディスクがネックになる問題は無いでしょう。 1インスタンスのみを使うということから、ネットワーク帯域がネックになる可能性も無いはずです。 ほぼ確実に CPU ネックな問題が出るはずです。 ア
livedoor Techブログ : ISUCONやりましたーっ！ 最終結果発表 #isucon
ライブドア技術部会の伊勢幸一です。 去る 2011年 8月 27日(土曜日で隅田川花火大会の日)、いい感じにスピードアップコンテスト ISUCONを開催しました。参加者の皆さん、見学者の皆さん、関係者の皆さん、おつかれさまでした！あんど、ありがとうございました。おかげさまで予想以上に盛り上がり、つぶやきやブログエントリー等を見る限り皆さんに楽しんでいただけたようで、スタッフ一同開催してよかったと心から思っています。また、副賞の書籍をご提供して頂いた技術評論社様にこの場をお借りして心より御礼申し上げます。技評さんはエンジニアの味方ですねっ！（あたりまえかｗ） ここで、改めまして、コンテストの最終結果発表をさせて頂きます。 と、その前に ・・・・ コンテスト終了後、即時計測の結果に基づき優勝1チーム、準優勝1チームを表彰させていただきましたが、その際、最終的な結果確認の段階で得点のチェックにミ
isuconお遊びチーム（事前社内β組）の設定あれこれ - hideden.hatenablog.com
ISUCONに行ってきました。社内での事前βテストに参加して問題を知っていたので出場はせず。社内β参加を持ちかけられたときは、正直「めんどくせーなｗ」が素直な感想だったんですが、実際にやってみるとスコアがリアルタイムにわかる＆ちょっとずつ自分のスコアが上がっていくってのは楽しくて、わりと本気でチューニングしてしまいました。 さて、本戦でも14時頃からお遊び用としてサーバー一式が解放されたので、大人げも無くそこで112500req/minをたたき出して参加者のやる気を削いだ（・・と懇親会で言われました。色々すいません！）構成について。 reverse proxy nginx(1.0.5) ngx_http_memcached + ngx_http_ssi_filter + ngx_http_scgi + ngx_http_upstream_keepalive(3rd party plugin
おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました
まずは、ライブドアの皆様、素晴らしいイベントの提供本当にありがとうございました。めちゃくちゃ楽しかったです。 Kayacのエンジニア3人 @fujiwara @sugyan @songmu の3人でチームfujiwara組を結成し、結果優勝することができました。 実際は周りの認識通り、@fujiwaraさんに優勝させてもらったようなもので、@sugyanと僕は手を動かしていただけです。まあ、空気にならずには済んだので、そこは安堵しています。 修正したisuconソースはフォークしてGithubに置きました。プログラムの修正部分のみで、my.cnfの修正なんかはここには反映されていません。 さて、@fujiwaraのコンテストでの動きや、帰宅後のBlogアップまであらゆる仕事が速くてビビるんですけど、詳しくは、#isucon で優勝してきましたを見てもらうとして、 どういうドタバタがあったの
#isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
