#isucon2 で優勝してきました - 酒日記 はてな支店
なんでもありのいい感じにスピードアップコンテスト ISUCON が 2 になって帰ってきたので、参加して優勝を勝ち取ってきました。 まとめ的なものはこちらから livedoor Techブログ : ISUCON チームメンバーのblogも併せてご覧ください。 おそらくはそれさえも平凡な日々: #isucon2 で連覇させてもらってきました Redis布教活動報告 ISUCON 編 - unknownplace.org 今回は前回の ISUCON 優勝メンバーのひとり @sugyan が転職して出題側に回ってしまったので、@typester を招聘してチーム編成。@songmu と共に3人でチーム「fujiwara組」として再参戦です。 以下、作業用IRCのログからふりかえりますと…… 11:39:29 <typester> とりあえずrecent_soldはキャッシュってのはまずやることか
#isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、
#isucon で優勝してきました - 酒日記 はてな支店
なんでもありのWebアプリケーション高速化バトル、#isucon に会社の同僚 @Songmu @sugyan と3人で、fujiwara組として参戦してきました。結果、幸いにも優勝を勝ち取ることが出来ました。 こんなに楽しいイベントを企画、運営していただいた Livedoor の皆様、本当にありがとうございます！！ さて、ざっとチューニングした経過などを記録しておきます。 [追記] もっと詳しいレポートを @Songmu が上げているのでそちらもご覧ください おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました [さらに追記] #isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店 自分でももう少し詳しく振り返りエントリ書きました。 まず説明を聞いて、環境を作るところから。IPアドレスでは作業がしにくいし事故も起こりそうなので、host
nginx の組み込み Perl で独自の認証をかける - 酒日記 はてな支店
独自の認証機能付き HTTP ダウンローダを提供するために、nginx の組み込み Perl を使ってみました。 公式のドキュメントはこちら。EmbeddedPerlModule - Nginx Community 自前の handler でリクエストをみて処理を行い、許可するなら DECLINED を返して後続の処理に任せる。そうでなければ Fobidden を返しておしまい、という流れです。 package MyAuth; use strict; use warnings; use nginx; sub handler { my $r = shift; if ( $r->header_in("MyAuth") ) { # なにか独自の認証をする(ここではリクエストヘッダを見るだけ return DECLINED; # 処理を継続させるために DECLINED } $r->status(
TheSchwartz で時間が掛かる job を実行するときは grab_for に注意 - 酒日記 はてな支店
TheSchwartz の worker で、一つの job が worker->grab_for (default 3600) 秒以上掛かる処理をすると、処理中の job を他の worker が掴んでしまう。 具体的には大量のメール送信をしていたんだけど、Data::Valve でスロットリングしてゆっくり送っていたら 1時間以上掛かって、別の worker も同じ job を実行してしまった。結果、同じメールが 2通ずつ出た orz grab_for は job を処理しはじめた worker が、失敗を報告もできないでクラッシュした場合に、別の worker が処理できるようにするもの。しかし送信してしまったメールは取り消せないからな…… package MyWorker; use base qw/ TheSchwartz::Worker /; sub grab_for { 60
TheSchwartz の worker を安全に停止する - 酒日記 はてな支店
TheSchwartz の worker を Ctrl-C とか kill で止めた場合に、job の処理が半端な状態で終わられると困る、という話。以前 Deamon::Generic で TheSchwartz の worker をデーモン化する(2) - 酒日記 はてな支店 で諦めたんだけど、ちょっと必要に迫られたので考えてみたら一応できたっぽい。 package MyWorker; use strict; use warnings; use base qw( TheSchwartz::Worker ); sub sighandler { warn "caught signal @_\n"; no warnings 'redefine'; *TheSchwartz::work_once = sub { exit }; } sub work { my ($class, $job) = @
TheSchwartz を PostgreSQL / SQLite で使うと worker プロセスが太る(のは解決済) - 酒日記 はてな支店
MySQLだと問題ないみたい。あと、job の引数に何を渡すかで変わってくるらしい…… [2010-2-16 追記] 追記時点での DBD::Pg と DBD::SQLite の最新版 (DBD::Pg-2.16.1, DBD::SQLite-1.29) では、以下に記述されているメモリリークは解消されています。記事自体は記録の意味も兼ねているので消さずに残しますが、ご注意ください。 ちなみに SQLite 用のスキーマは TheSchwartz 自身に同梱されていて t/schema-sqlite.sql に、PostgreSQL 用のはリポジトリの trunk にあります。doc/schema-postgres.sql 検証用のスクリプトは最後に載せますが、単に client が job を突っ込んで、worker が job を取り出して $job->completed() するだけ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
