ISUCON4本選で3位に敗れました #isucon - 酒日記 はてな支店
ISUCON4 に「fujiwara組」として参戦しましたが、既報のとおり 3位に敗れてきました。順位こそ3位で賞金10万円は獲得できたものの、スコアが示すとおり内容的には完敗です。 まずは主催のLINE社様、出題を担当していただいたCookpad社様、本番サーバ提供をしていただいたテコラス社様にお礼申し上げます。本当に楽しいイベントをありがとうございました。 うちのチームとしてやったことは #isucon 4の本戦で3位を取ってきました (追記あり) - beatsync.net に大変詳しいので、そちらをご参照ください。 簡単に最終的な構成をまとめると Redisは1号機に(動画以外)集約 動画はアップロードを受けたサーバがローカルファイルとして保存しnginxが返す。保存されたサーバのアドレスをメタデータとしてRedisに保存し、APIへのレスポンスに含まれるURLを構築するのに使用
#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はキャッシュってのはまずやることか
cron で > /dev/null して椅子を投げられないための3つの方法 - 酒日記 はてな支店
(タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルが twitter で流れてきたのを見て、「そうだ！出力を /dev/null に捨てるなんてとんでもないよね！」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでつい crontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかく cron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、
Parallel::Benchmark というモジュールを書きました - 酒日記 はてな支店
プロセスを並列に立ち上げて負荷を掛けるようなベンチマークを実行することって、よくありますよね。(例 : クエリキャッシュを切ったほうがいイカ？ ベンチマークしてみた - 酒日記 はてな支店) Perl で Parallel::ForkManager を使うとそういう処理も簡単に書けて便利なのですが、何度も同じようなコードを書くうちに、これもうちょっと抽象化したら使いやすいかも、と思って Parallel::Benchmark というモジュールを書いてみました。 リポジトリはこちらです。 https://github.com/fujiwara/p5-Parallel-Benchmark たとえばフィボナッチ数 fib(10) を求めるベンチマーク。 use Parallel::Benchmark; sub fib { my $n = shift; return $n if $n == 0 o
Perl から Fluentd にログ出力 - Fluent::Logger リリース - 酒日記 はてな支店
皆さん、ログ書いてますか！？(挨拶) Fluentd meetup in Japan も開催間近、最近大変熱いイベントログ収集システム Fluentd なわけですが、Perl からログを出力する Fluent::Logger というモジュールを CPAN にリリースしたのでお知らせします。 (最初の版は id:hirose31 さんが書かれて、それに同僚の id:shin1rosei と手を加えたものです) インストールは cpanm などでどうぞ。使い方は POD にもあるように簡単です。 use Fluent::Logger; my $logger = Fluent::Logger->new( host => "127.0.0.1", port => 24224 ); $logger->post( "myapp.info" => { foo => "bar" } ); 上記の例で送信す
#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
MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店
前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。 master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。 台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。 slave * 2 → 残り 1台で処理継続 生き残った1台あたりの処理が 2倍になる slave * 3 → 残り 2台で処理継続 生き残った1台あたりの処理が 1.5倍になる たとえば 1台あたり最大 1000qps の処理能力があるとします。sla
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
Kamakura.pm techtalk #1 (とか転職のお知らせとか - 酒日記 はてな支店
Kamakura Perl Mongers 発足ということで、テクニカルトーク #1 にスピーカーとして参加してきました。 # というかスピーカー枠に埋められていたというか スライドはこちら→Sys::Virt で仮想マシン操作 ですが、かなり手抜きですみません。トークの後半分ぐらいは gist にあげたコード の解説でして、最近は関数型言語っぽい書き方が好きなのでそんな感じになってます。 本題の Sys::Virt については、現状、実際何か運用しているわけではなく、こんなものがあるから面白いかもねーというレベルです。 ところで typester さんの言によれば「kamakura.pm ではテクニカルトークはあんまりやりません」ということでして……基本的には、鎌倉(神奈川)周辺の人たちが気軽に Perl の話をしながら飲んだりするような集まりをやっていこう、ということのようです。次回開
mod_pagespeed をちょっとだけ試してみた - 酒日記 はてな支店
Google の Page Speed の Apache module 版 mod_pagespeed をインストールして、ちょっとだけ動きを見てみた。 インストールは Ubuntu に deb パッケージで。 $ wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_amd64.deb # sudo dpkg -i mod-pagespeed-beta_current_amd64.debconfig はデフォルトで入るものそのまま。 <IfModule pagespeed_module> SetOutputFilter MOD_PAGESPEED_OUTPUT_FILTER ModPagespeed on ModPagespeedUrlPrefix "http://localhost/mod_p
Digest 認証と Reverse proxy の話 - 酒日記 はてな支店
昨晩 twitter で、「バックエンドのほうで Digest 認証されているところに mod_proxy で Reverse proxy できない」という話があったのでちょっと試してみた。 あれ？mod_proxyとかだとdigest認証出来ないのか？リバースプロキシにアクセスした時点で認証させる形とかmod_rewriteでゴニョゴニョさせる方法とかしか無いのかな。 2010-10-19 19:17:04 via Tween 結論から言うと、 uri (path) が表と裏で同一なら問題なし 別の uri ( 表:/foo => 裏:/bar など ) だと認証に失敗する という結果に。 Digest 認証のアルゴリズムでは、Authorization ヘッダの生成に uri も使用するため、クライアントが認識している uri とバックエンドが認識している uri が異なるとヘッダの検
YAPC::Asia2010で「nginx & Perl」の発表をしてきました - 酒日記 はてな支店
YAPC::Asia2010 で、「nginx & Perl」という題名で20分の発表をさせていただきました。 発表資料はこちらにあげてあります 内容はざっくり nginx とおもしろげなモジュールの紹介、組み込み Perl の使いかたと注意事項、Plack Server に Reverse Proxy する場合の設定例などです。 資料内で Lighttpd は single process という記述がありますが、「最近 Lighttpd も fork するようになった」(@myfinder さん) とのご指摘を受けました。ありがとうございます。 あと、言おうと思ってて言い忘れたのですが、「nginx の if はネストできないし else もないので、複雑な rewrite をする場合は組み込み Perl 使ってやるのもアリじゃないかな」と思ってます。「柔軟な config を書くため
YAPC::Asia2010 iPhone アプリの顛末とか - 酒日記 はてな支店
後夜祭が終わって帰宅途中、不意に 今更 #yapcasia のiPhoneアプリ顛末について飛び込みLTすればよかったなぁと思いついた。後の祭り。 2010-10-16 23:09:56 via TwitBird と思ったのですがこれはまさしく後の祭り。なのでせめて顛末を書いておきます。 YAPC::Asia 2010 Tokyo iPhone アプリというのを公開しました。 http://itunes.apple.com/jp/app/yapc-asia-2010-tokyo/id396664124?mt=8 Opening talk で紹介していただいたので、ダウンロードしていただいた方も多いかと思います。 これは一から書き起こしたものではなくて、 某 IRC で「iRubyKaigiのiPhoneアプリ みたいなのが YAPC にも欲しいよね」という話が出て githubで修正BSD
OAuth::LiteでOAuth対応のHTTP::Requestを作る方法 (Perlでtwitter bot書いてる人向け) - 酒日記 はてな支店
最近人気エントリーに便乗したネタが多くてすみません。 実用！ PerlでコマンドラインからTwitter投稿（OAuth対応） では、Net::Twitter を使って OAuth で投稿する方法が紹介されていますね。 ところで、単純な twitter bot 作るのに Net::Twitter 使います？「投稿なんて LWP で1発リクエスト投げればいいだけだから使わない」という人も多いと思いますが、Basic 認証が廃止されたらどうしましょう。 そのようなかた向けに、OAuth::Lite で OAuth 対応な HTTP::Request を作る方法をご紹介します。 consumer key, consumer secret, access token, access token secret は既に何らかの方法で取得できているものとすると、こんな感じです。 use OAuth::L
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
