予選問題のベンチマーカーと参照実装のコードと、Ubuntu 16.04 上に予選問題を動くようにするための手順を公開します。感想戦にご利用ください。 予選問題のリポジトリ 複数台構成について今年のISUCON予選では、予選としては初めて複数台構成を利用してみました。 倍率が高くなった現代のISUCONにおいては、多くの参加者にとって予選こそがISUCONになるということを念頭に、ISUCONの醍醐味で予選でまだやってないのはなんだろうと考えたときに思いついたのが複数台構成でした。 また、1台あたりの性能を厳しく制限することで、1プロセスで簡単にマルチコアを活かせるGoが強くなりすぎないようにするという考えもありました。サーバー1台あたりのCPUは1コアしかないので、Goでも他の言語でも複数コア数を使いたければ複数サーバーを使うしかありません。メモリも1GBしかないので、1台で捌く状態でチュ

こんにちは、非常勤ライターのひにしあいです。 今日は東京からおよそ3時間、三重県四日市の楠駅に来ています。この小さな駅に何をしに来たかというと― 下町で愛されまくっている『キンミヤ焼酎』が作られているから……！ 東京下町の居酒屋で絶大に愛されている「キンミヤ焼酎」は、芸能人でファンを公言する人も多く、おじさまたちだけではなく若年層にもその人気は広がっています。 このラベル、飲み屋さんなどで一度は見かけたことがあるのではないでしょうか？ しかし、この「キンミヤ」―ずっと古くからあったにも関わらず、4～5年前から「甲類焼酎といえばキンミヤ」というイメージがなぜか急速に広まりブームになったという状況で……一体何が原因なのか、以前から気になっていました。 ということで、『キンミヤ焼酎』を作っている製造元「宮崎本店」の社長と― 飲みにきました いきなりの急展開で何を言っているのか分からないと思います

最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En

属人化の理由 個人の問題 手抜きやバグを隠す たとえば、仕様書外の動作を実装し、それをプロジェクトで利用する 解雇されないための保険的行動 チームの問題 マニュアルを作る文化の欠如 他人のタスクに対する無関心 他人の監査なしにプロジェクトを更新可能 どうやって属人化を避けるのか 間違った対策 ○○さん以外にもマニュアルなしで操作できる人間を育成 育成した人が全滅すればやっぱり同じ状況 全員がすべてのプロジェクトに精通するとかはムリ 正しい対策 モジュールごとに仕様書を用意 間違って使うことが難しい仕様とする 即ち、仕様書を読まなくてもある程度正確に使える お互いにコードレビューさせる 具体的にはどうすれば良い？ テスト・仕様書・利用例 テストは仕様書のベースとなる 仕様書を見れば、深い動作がわかるようになる 仕様書を読まなくても、利用例を見れば使える 全員がテストできる環境を作る 前提条件

Intro ブラウザはリロード時に、 max-age に満たないキャッシュを持っていても Conditional GET によってキャッシュの Validate (有効性の問い合わせ)を行う。 Cache-Control Extension として提案されている Immutable 拡張は、キャッシュが max-age 内であればリロード時もキャッシュヒットさせる拡張である。 このヘッダの効果と、本サイトへの適用について記す。 Cache-Control Cache-Control に max-age を指定することで、ブラウザにリソースをキャッシュさせることができる。 このキャッシュは max-age の期間内は fresh とみなされ、 fresh であればサーバへの問い合わせなく再利用される。 サーバへの問い合わせ(RTT)が無いため、事実上最速のリソース取得となる。 Reload

あー、負けたー。「Asakusaの方から来ました」というチーム名で、Asakusa.rbでよくいっしょする @joker1007 さん、および @yancya さんと出た。最終結果は111400くらい? ただし20時*1を過ぎても4〜6万くらいをうろうろしてて、最終的には20:10頃に入れた変更でスコアが倍になり、なんだこれー? と言ってる間にタイムアップした。 去年のISUCON6決勝はやるべきことをやれなくて負けたので素直に悔しかったけど、今年はなんか問題設定の意図がまったくわからなくてそのまま不完全燃焼で手が停まって4時間経過で死んだという感じなので、なんだかなー、という気分。あんま疲れないまま終わってしまった。 なんか、なんで自分があーって思ってるかはわかった。keep-aliveをなかなか切ってくれないエンドユーザクライアントがたまに混ざってくれることはあるかもしれないけど、CD

とてもとても悲しいので、とりあえずやったことと言い訳を書いて気を紛らわせることにする。 敗北した身でグダグダ言うのが格好悪いことは百も承知だが、人間には魂の救済が必要であることをご理解いただきたい。 序盤〜方針決定 最初パスワードのコピペミス等でサーバーからガンガンBANされて、そもそもログインできなくなる。これで10分から20分ぐらい無駄にした気がする。 テザリングにIPを切り替えたり、他のノードから入ったりして、何とか公開鍵でログインできる環境を整える。 適当にベンチ流してスコアを取る前に、nginxのログ設定や構成を確認しalpを使って集計できる準備を整えた。デフォルト実装とRuby実装でベンチを流す。その裏で実装を一通り読む。 ざっくり図を書いて、相談。とにかく/iconsを何とかしないと話が進まないので、静的ファイルとして書き出してCache-Controlだよね、までは即決。

ISUCON、見事に予選落ちしました。憂鬱な火曜日で出てました。言語はRubyを選択しました。 やったこと nginxアクセスログ解析 kataribeを使ってアクセスログの解析を行った。 message、login、iconsあたりが遅いことが判明。 特にiconsがボトルネックになっていたので、icon取得部分を改善することにした。 icon取得部分の改善 以下のSQLを実行するとユニークの画像件数が67件しかないことが判明 SELECT MIN(id), name, data FROM image GROUP BY name, data とりあえず、重複行は全て削除 DELETE FROM image WHERE id NOT IN ( SELECT i FROM ( SELECT MIN(id) AS i, name, data FROM image GROUP BY name,

去年に引き続き id:arata3da4 id:jp_taku2 と ISUCON に出場した。 今年の最終スコアは 26,772 点で、決勝進出することはできなかった。 しかし昨年の最終スコア 0 点と比較すると +Infinity 倍のスコアを記録できたことになる。 圧倒的成長！！！ blog.hotolab.net (昨年の人権を失っていた頃の様子) 開始時間の遅延 #ISUCON のために 7 時に起きるぞって思って寝たら 06:59 に目が覚めたの凄くないですか— ほと (@hoto17296) 2017年10月20日 気合い入れて7時に起床して8時半には準備完了して集中力を高めていたら、まさかの開始時間が3時間もの遅延。 これが #ISUCON か... pic.twitter.com/VML0PWkQfu— ほと (@hoto17296) 2017年10月21日 時間が空いた

ISUCON7予選に「railsへの執着はもはや煩悩の域であり、開発者一同は瞑想したほうがいいと思います。」チーム (@cnosuke, @rkmathi, @k0kubun) で参加し、217,457点で予選通過だったようです。 正確な値は覚えてませんが、Best Scoreは25万くらいでした。 最終形の構成概要 appサーバ1 puma 16スレッド: 画像のアップロード/表示、雑多なリクエスト対応 puma 2スレッド: GET /fetch だけ返す appサーバ2 puma 16スレッド: 雑多なリクエスト対応 (画像はnginxがサーバ1に流す) puma 2スレッド: GET /fetch だけ返す DBサーバ MySQLがいるだけ サーバ1, サーバ2をベンチマーク対象にしていました。この構成なのは GET /fetch がスコアにカウントされないため、それ以外にほとんど

スギャブロエックス（id:sugyan, id:kazeburo, id:gfx) で予選に出場して2日目2位でした。去年は予選敗退だったので2年ぶりの本戦出場です。 バランスの良い良問で大変楽しかったです。ISUCON運営チームに於かれましては大変おつかれさまでした＆ありがとうございました。 isucon.net スギャブロエックスのスコア推移: repo: https://github.com/gfx/isucon7-qualify 言語 採用言語はnodejsでした。もともとはPerl界隈で知り合った3人ですが、最近だれも現役でPerlを書いておらず、go, ruby あたりでやるか〜みたいな話を最初していました。途中でnodejs実装が追加されることになったので、nodejsにしたい！と希望してこうなりました。 スギャブロエックスがnodejsだと…— Ryuta Kamizono