ホーム

へぼい日記

#isucon 8 本戦10位で負けてきました

  • 投稿者: chiba
  • 2018/11/3 土曜日 21:28:22
  • ISUCON

ISUCON8本戦に山形組でISUCON6以来の2年ぶりに参加してきました。結果は既報の通り学生チームである「最大の敵は時差」さんが優勝され、我々は10位という残念な結果となりました。(そういえば今回、本戦の結果の受賞チーム以外の公式発表が対参加者以外にないですね)

山形組の過去を振り返ると

ISUCON1、下から数えたほうが早い順位
ISUCON2、準優勝かつ特別賞
ISUCON3、予選総合3位本選5位
ISUCON4、予選総合4位本選10位
ISUCON5、予選落ち
ISUCON6、予選総合2位本選10位
ISUCON7、予選落ち
ISUCON8、予選総合15位、本選10位

とまあ、なぜか2年おきに本戦出場し10位になるということを繰り返しております。来年はジンクスを打ち破って2年連続で予選突破して本戦優勝を果たしたいです。

やったこと

  • 選んだ言語はもちろんPerl
    • 初期スコア: 1588
  • 最初のお決まりの作業
  • ただ、すべてがdocker上でうごいていて、よくわからん…となったので、とりあえずログをいつものようにとるためにnginxを剥がす
    • ここで妙にはまって時間を消耗
  • 12:53 遅めの作戦会議。スプレッドシートに共有した作戦リストが以下。見積もり時間と担当を決めてそれぞれとりかかる。
    – N+1の地道な解決
    – はやくなったら、enable_shareをonにする
    – ログ送信用のワーカーをつくり/bulk_send を実装
    – static expires max
    – isu4 の mysql を利用する
    – appをisu2,3に並列稼働
    – appをdockerからはがす
    – app のプロセスの状況を見る
    – cache関連
  • 13:19 score:2560
    SELECT * FROM trade ORDER BY id DESC
    LIMIT 1
    追加
  • 13:46 score:2756
    ALTER TABLE `isucoin`.`trade`
    ADD COLUMN `created_at_sec` DATETIME(6) NULL AFTER `created_at`,
    ADD COLUMN `created_at_min` DATETIME(6) NULL AFTER `created_at_sec`,
    ADD COLUMN `created_at_hour` DATETIME(6) NULL AFTER `created_at_min`,
    ADD INDEX `idx_sec` (`created_at_sec` ASC),
    ADD INDEX `idx_min` (`created_at_min` ASC),
    ADD INDEX `idx_hour` (`created_at_hour` ASC);
    
    update trade set created_at_sec=STR_TO_DATE(DATE_FORMAT(created_at, '%Y-%m-%d %H:%i:%s'), '%Y-%m-%d %H:%i:%s'),created_at_min=STR_TO_DATE(DATE_FORMAT(created_at, '%Y-%m-%d %H:%i:00'), '%Y-%m-%d %H:%i:%s'),created_at_hour=STR_TO_DATE(DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00'), '%Y-%m-%d %H:%i:%s');
    結果意味なかったかもしれないけど、秒、分、時の切り捨てをあらかじめ行うように。
  • 14:02 score:4351
    Starletのworkerを5->15に
  • 14:13 score:4530
    staticファイルをnginx serve/expires max
  • 15:00 score:4673 orders.userのN+1外し
  • 15:24 score:4144 isu4のDB参照(2台構成へ)
  • 15:47 score:4726 tradeのN+1外し
  • 16:04 score:4904 isu2/isu3にround robin(4台構成へ)
  • 17:34 score:8191 enable_shareを1/7(約14%)有効に
  • 17:49 score:8389 enable_shareを 22% 有効に
  • その後いろいろshare rateをいじるが最終提出は22%で、最終走行では score:9473 で10位

上記に書いてないこととして、テーブルのパーティショニングには気づいて、外すのを試したりしていたのですが、逆に大幅スコアダウンしたりしていてもとに戻したりしていました。後から考えてみると、チーム連携がうまくとれてなくて関係ない変更がまぎれていたのか、DBのウォームアップ的な問題だったのか…。

全体的にdocker絡みで操作にまごつくことが多くて、最初から予定していたbulk_sendの実装もできないほど時間が足りない状態に陥ってしまい、少ない残り時間をenable_shareのrate調整という本質的ではない作業に割いてしまっていました。肝心のtrade部分のチューニングは考える時間すらほとんどとってなかった状態でして、バックグラウンドにまわして直列化するなんてまったく考えついてもいなかったので、完敗ですね…。banの実装もやろうともしていなかったです。

感想戦

先週末、感想戦をやりきれるだけやりきってみました。そこでやったことはこちら。(細かくscoreとってないので大雑把ですが

  • /send_bulkをbackgroundプロセスで実装
  • score:11318 tradeをbackgroundで0.1秒おきに実行
  • score:32245 chart_by_*をsettingsテーブルにcache
  • score:40999 remove partition/bcrypt cost
  • score:53800 5回連続ログイン失敗のban
  • score:67402  isuconbank:commitを run_tradeからさらにbackground化してrun_tradeを早くまわすように
  • score:74507 lowest/highestとかもcache
  • score:113736 nginxのworker_rlimit_nofile 4096;
  • score:137392 tradeのロジック最適化/settingsのプロセス内キャッシュ/isubank,isuloggerのhttp keepalive
  • どこでやったかわすれたのですが 
    /etc/sysctl.conf

    net.netfilter.nf_conntrack_max = 100000
    net.nf_conntrack_max = 100000
    を追記

といったところで、13万点超えでその時点での感想戦1位をとって満足してやめていたのですが、翌朝おきたら40万点超えの学生チームが現れており、ただ笑うしかなかったです。

感想

感想戦をやってみて改めて実感しましたが、いろいろなところにボトルネックが隠されており、総合力が試されるとてもよい問題でした。

毎度のことながら来年のことはまだ決まっていないと思いますが、開催されるようであれば、もちろん参加したいです。

出題を担当された、カヤックの方々、協力をされていたDeNAやその他の方々、運営のLINEのみなさまには感謝です。こんなに熱く楽しいイベントの開催を毎年維持されており本当にすごいことだと思います。ありがとうございました!

はてなブックマーク - #isucon 8 本戦10位で負けてきました

#isucon 8 予選15位で通過しました

  • 投稿者: chiba
  • 2018/10/10 水曜日 21:05:09
  • ISUCON

毎年でているISUCONに今年も山形組として参加してきました。

結果は総合15位ということで、ギリギリでしたが予選通過しました。第1回からずっと同じ2人チームで参加していて、本戦出場回数は6回(1, 2, 3, 4, 6, 8)になったみたいです。そろそろ本戦優勝したいです。

やったこと

  • 事前準備は空レポジトリ作成と、情報共有と秘伝のタレのコピペ用のスプレッドシートの作成など
  • 選んだ言語はもちろんPerl
    • そろそろGoで挑戦しますか?というのを3年ぐらい言い続けて未着手
    • 普段の仕事はPerlなので手に馴染んだ道具を使うということでいいと思っている
  • 最初のおきまりの作業
    • 初回ベンチ
    • 初期コードのレポジトリコミット
    • デプロイスクリプト用意
    • アプリの挙動確認
    • コードリーディング
    • 作戦会議
    • ここまでで2時間ほど
  • 作戦会議
  • ISUCON7のときのCache-Control: publicISUCON4のときのCache-Control/Expiresの悔しい思いがあるのでキャッシュ関連を調査
    • HTTPのreq/resヘッダーを未知のものも含め全てログ保存する自作のPSGI middlewareを用意して、ベンチ中の全ヘッダーをみれるように
      • 同じことをやるmiddlewareがないので整理して公開してもよいかも
    • 各種キャッシュ関連のレスポンスヘッダをいろいろと付与して、appにくるアクセスでは条件付きリクエストの類はまったく行われないことを確認
  • 実際に行った改修
    • 12:52 sheetsテーブルのインメモリ化
    • 13:41 h2o -> nginx
    • 14:14 座席の詳細いらないときにも内部的にはとってきているのを省略
    • 15:22 残席数の取得を1SQLに。こういうSQL各所に書いた。
      SELECT e.*, count(case when r.sheet_id between 1 and 50 then 1 else null end) as reserved_S, count(case when r.sheet_id between 51 and 200 then 1 else null end) as reserved_A, count(case when r.sheet_id between 201 and 500 then 1 else null end) as reserved_B, count(case when r.sheet_id between 501 and 10000 then 1 else null end) as reserved_C FROM events e left join reservations r on (r.event_id=e.id and r.canceled_at is null) WHERE e.id = ? group by e.id
    • 15:43
      where public_fg=1
      をPerlでやっているのをSQL化
    • 15:43 reservationsにindex追加
       KEY `event_id_and_sheet_id_idx` (`event_id`,`sheet_id`),
        KEY `event_id_cancel` (`event_id`,`canceled_at`)
      
    • 16:05 get_event内でreservationsに全シート分の1000回クエリなげてるところを1回に
    • この時点でスコアは 18,992 でベストスコアで3-4位あたり
    • 16:13 isu1のオールインワン構成から isu1-web/app isu3-dbに(isu2はこのあと最後まで遊ばせることに…
    • 16:55 いくつかのFOR UPDATE消し/ IFNULL(canceled_a, reserved_at)をmodified_at化
    • 17:00 他チームのスコアが非公開になるタイミングで、スコア: 44,450でベストスコア2位で折り返し
    • 17:24ごろ get_login_userの呼び出し抑制、FOR UPDATEの削除
      • このあたりで、ベストスコアの 57,093
    • event_sheetsテーブルを新設して、予約を
      UPDATE event_sheets set reserved=1, hash=? where event_id=? and rank = ? and reserved=0 order by rand() limit 1

      というSQLでやるというのをいれたけどスコアが下がり取り下げ 
    • ~18:00 取り下げたけどその後スコアが安定せず、実行するたびに2万台~3万台をうろうろ
    • 最終スコアをなんとか 39,677 にもっていき終了

感想

最後スコアが安定しなかったのは、FOR UPDATE消したことも影響しトランザクションにミスがあったことが原因だというのは感想戦でわかりました。なので正直最後は運もあったなぁという感じはしています。

感想戦ではその後
– isu1-web/app isu2-app isu3-db の3台構成に
– event_sheetsの件を再投入
– 適切なトランザクション
で10万点までとれました。

予選での複数台構成、コードのボリューム、ベンチの快適さ、運営全体のストレスのなさ、すばらしい予選になっていたと思います。(通過したからというバイアスもありますが)

karupaneruraさんをはじめ出題担当されたDeNAの方々、カヤックさんはじめ協力されていた方々、LINEの運営を担当されている方々には感謝です。

ということで、何はともあれ、本戦にまた参加できることになり嬉しいです。
今度こそ優勝だ!

はてなブックマーク - #isucon 8 予選15位で通過しました

#isucon 7 予選敗退しました

  • 投稿者: chiba
  • 2017/10/29 日曜日 13:10:52
  • ISUCON

毎年でているISUCONに今年も山形組として参加してきました。

結果は71位ということで、つまり惨敗してきました。

やったこと

選んだ言語はPerlでした。やれたことは、

  • 全3台でnginx/app 1台でDB構成に
  • index貼り
  • (中途半端だけど)クエリチューニング
  • 既存画像のファイル化と全3台への配置
  • 新規画像のファイル化と他2台への配置
  • /fetchだけfeersumにしてプロセスが詰まらないように
  • /fetchをsleep 9秒にして新規投稿があったらすぐに返すように

で、Bestスコア 81,227, 最終スコア 50,956

やれなかったこと

競技後のネタバラシで気づいたことは

  • Cache-Control: public
  • 画像ファイルの更新時間あわせ

後者は完全なる自分のミスで、競技中にEtagが揃ってるかということは気にして確認したのですが、たまたま確認したファイルは揃っていた(か確認ミスしていた)ため、強制的に揃える仕組みで配置していなかったことに気づかず終わりました。
画像をファイル化してからボトルネックが帯域だと分かっているのに4時間ほど何もできないままでした。
本戦出場されているみなさんのblogをみていると、リクエストHTTPヘッダを冷静に分析するとか、Cache-Controlの仕様を読み直すとかやれることは確実にあったので、実力不足を痛感しました。

Cache-Control: public

これつけなくても普通はキャッシュするジャンスカともやっとしていたのですがRailsのアセットパイプラインのドキュメントだとpublicをつけることが例示されていて、実際にGCPのCDNでは“Cache-Control: public ヘッダーがある。”というのがキャッシュの条件として明示されていることも確認できました。

静的ファイルのCache-Control: publicは今後は実務でもつけていこうという知見を持ち帰ることができました。

来年

人任せなので希望でしかないですが、来年あったらまた参加したいです。

出題チームのKLab、主催のLINE、サーバー提供のSAKURA internetの皆様、本当にお疲れ様でした。本戦もよろしくお願いしますといえないのが非常に残念ですが、本戦の様子がレポートされるのも楽しみにしております。

はてなブックマーク - #isucon 7 予選敗退しました

Web高速化請負事業はじめました

  • 投稿者: chiba
  • 2017/2/28 火曜日 13:25:31
  • 会社

http://e-dreamer.co.jp/wp-content/uploads/2017/02/pressrelease_20170228.pdf

本日上記のとおりリリースをだしましたが、Web高速化請負事業をはじめました。

このブログは一応会社ブログということでやっているのですが、ここ最近は会社でやっていることを書くでもなく社内有志で参加しているISUCONの報告ばかりになっていました。というわけで、趣味がこうじて事業を興すということに。

ビジネスにしてしまえばチューニングを仕事でもっとできるし経験値もあがるぞーという企みもあります。

つきましては、「遅いWebサービス」「重たいWebサービス」「いまひとつ快適さにかけるWebサービス」を抱えてお困りのお客様を募集いたします。
具体的には、たとえばこんな方をお待ちしております。

「直帰率が高く、原因が読み込み速度が遅いことに起因している」
「サービスが全体的に遅いからとにかく速くしたい」
「他社にチューニングの見積りを依頼したら、『イチから作り直さないとダメだからウン千万円』かかると言われた」
「前任者と連絡がとれなくなったので、何がなんやら」
「予算が限られているから、特定の機能だけ速くしたい」

http://secondlife.hatenablog.jp/entry/20110919/1316438465
そのむかし、Wantedlyをsecondlifeさんが高速化したことがありましたが、こういう事例を想定しています。

種々の制約がある方も、どうぞ諦めないでご相談ください。

高速化技術の例

SQLクエリ改善、DB設計改善

重くなる原因最多ですが、着実に改善させていただきます。

アプリケーションのチューニング

Web系の言語にはだいたい対応できます(Perl/PHP/Ruby/Python)。

サーバースペック、構成の計画

サーバースペックや構成が現状の利用状況に合っていない場合には、再構成計画の提案もさせていただきます。
ioDriveの提案も辞さないです。

お問い合わせ先

株式会社イードリーマー
山田/千葉(fastweb@e-dreamer.co.jp
電話:03-6427-3994  FAX :03-5778-3003

はてなブックマーク - Web高速化請負事業はじめました

#isucon 6 本戦10位で負けてきました

  • 投稿者: chiba
  • 2016/10/30 日曜日 17:41:42
  • ISUCON

ISUCON6本戦に山形組でISUCON4以来の2年ぶりに参加してきました。結果は既報の通り予選で1位だった「この技術部には問題がある!」チームさんが勢いそのままに優勝され、予選2位だった我々は本選では10位という残念な結果となりました。(予選の結果は本選には何も関係ありませんが)

山形組の過去を振り返ると
ISUCON1、下から数えたほうが早い順位
ISUCON2、準優勝かつ特別賞
ISUCON3、予選総合3位本選5位
ISUCON4、予選総合4位本選10位
ISUCON5、予選落ち
ISUCON6、予選総合2位、本選10位

とまあ、なんとも煮え切らない歴史になっており、せめてISUCON5で予選通過さえしてれば全部でてるんだと胸を張れた部分もあるんですが。

やったことなど

Docker( Compose)で Node.js, mysqld, App が起動されていて、かつNode.jsという特定の言語のアプリケーションが配布時は選択肢なく居座っているというのがいままでになく、Dockerはかろうじて遊びで触ってはいたけどNodeはチュートリアルすらやったことがないという状態で、これはやばい…というのが最初の印象。

で、いつものごとくAppはPerl実装に切り替え。

お絵かきをストリーミングで実装したアプリケーションってことで。お、ストリーミングは昔Plackの実装で遊んだことあるなー、必要になったらそのときのコード持ち出してやってみるかーと思ったものの結局できず。ストリーミングの部分、2秒以内であればPubSub的な実装でそれ以上はやくしてもスコアに直接は影響なかったようなんですが、mysqldへのポーリングがなくなって全体的にチューニングしやすくなったはずなので、やれなかったのは悔いが残るところ。

Dockerによる構成ついては、それ自体が勝敗を分けるパフォーマンス上のボトルネックになるわけがないと思ったので、当初はそのままでアプリケーションの改修をしていくことに。
ところがAppのコードの変更を反映する方法がわからず、イメージの削除をしてかなり時間のかかるbuildしなおしをする方法しか見いだせず…。これは開発上のボトルネックになるなと判断して、Appとmysqldについては外だしを行い、Node.jsはやったこともない環境構築で意味なくはまるのも怖かったのでそのまま。

フロントにNginxをたててTLS終端もそこで行いつつ、Node.jsをHTTPSからHTTPのサーバーに切り替え。
Node.jsのAPI-URLはNginxを一度経由するようにしてAPIをほかのサーバーに分散できるように。

全サーバーでAppを立ち上げてNginx経由で標準分散。

strokeとpointsの取得がN+1だったところを2回のクエリになるように調整。

C10kにはMonocerosやろってことで/api/stream専用のAppをMonocerosでたちあげ。(keep-aliveじゃなくて全プロセスがDBのポーリングしてるので意味なかったんだろうけど…)

あとは各プロセスのワーカー数の調整とmysqldのtoo many connection対策に腐心して終了。

ワーカー数の調整は/api/streamにめいっぱいふっとけばもっとスコアあがったのかもしれないなぁ…。

感想

構成に面喰いすぎて、普段やっている1時間後の戦略会議的なこともきちんと行えなかったし、全体的にふわっふわと場当たり的なことばかりしていて、よくある負けパターンに陥ってしまっていました。
ほかにもチームメイトとの連携など反省点はたくさんありますが、次回以降にそれを活かせるよう普段の仕事でも意識していければなと…。

過去のISUCONにそれなりにでている自分ですが、懇親会で周りを見渡してみると、参加者で一方的にでも顔を知っている人は優勝(経験)者の方とYappoさんのチームとあと何人かぐらいで、こうして普段接することのない人たちと競い合い、感想をぶつけあうことができるというのは本当に素晴らしいことだと思います。(あまり積極的に懇親するタイプではないですが…)
個人的な余談ですが、学生チームの中には自分の息子と同じ学年(高1)の方がいたそうで、そのチームにはなんとか勝ってたようなんですが、これはいよいよ大変なことになってきたぞと。

そして、はたしてISUCON7は開催されるのか…どこが出題するのか…。まだわかりませんが、開催されたらもちろんまた参加したいと思います。

予選・本選の出題者のみなさん、主催・共催をされた企業の方々、今年もめいいっぱい楽しませていただきました。ありがとうございました!

はてなブックマーク - #isucon 6 本戦10位で負けてきました

#isucon 6 予選二位で通過しました

  • 投稿者: chiba
  • 2016/9/24 土曜日 18:14:08
  • ISUCON

去年は初めて予選敗退し悔しい思いをしたISUCONに今年も山形組として参加してきました。

結果は総合二位で本戦出場を決めました。やった!

事前準備

前日にメンバーで作戦会議をして、「フルスクラッチ書き換えはやらない」という方針で大決定。過去フルスクラッチ書き換えでそこそこの結果を残してきた我がチームですが、去年の予選で手痛い失敗をしたのもあり今年は確実に予選を突破しようということで封印することになりました。

過去問を改めて解いたりはしなかったですが、matsuuさんのazure-isucon-templatesの一つをazureにdeployしてみて、なるほどazureはこういう感じかというのを確認したりはしていました。

当日

10:00

はじまっておもむろにazureにdeployしたところ

テンプレート デプロイ 'Microsoft.Template' は、検証プロシージャによって無効と判断されました。追跡 ID は 'a080b1d6-56fc-47d7-9228-9de96209bd0e' です。詳細については、内部エラーを参照してください。使用方法の詳細については、https://aka.ms/arm-deploy を参照してください。 (コード: InvalidTemplateDeployment)

というエラーがでてしばらく苦しめられる。もしやとおもい検証用にdeployしていた過去問のリソースを削除したら解消。

https://twitter.com/fujiwara/status/774853075668303872
fujiwaraさんのこのtweetはもちろん見ていたので、事前に従量課金サブスクリプションを作っていたんですが、今確認したら従量課金なのに無料試用プランであることには変わりがないようで、これどうやって解放するのかわからん。さようならazureという気分です。

deploy完了後、初期状態でPerlで動いていることを確認し、そのまま行くことに。
その後1時間ほどは

  • 初回ベンチ実行
  • コードのローカルへの転送とgitへの展開
  • nginxアクセスログを解析用に修正
  • カーネルパラメーターやapt-get, cpanfileの秘伝のタレの投入
  • コードの解読
  • プロファイリングするまでもない明らかにボトルネックになるポイントをさくっと修正

などをやる。プロファイリングするまでもない明らかにボトルネックになるポイントの修正は具体的には

  • ON DUPLICATE KEY UPDATEの無駄なデータの二重転送排除
    -        author_id = ?, keyword = ?, description = ?, updated_at = NOW()
    -    ], ($user_id, $keyword, $description) x 2);
    +        author_id = VALUES(author_id), keyword = VALUES(keyword), description = VALUES(description), updated_at = NOW()
    +    ], $user_id, $keyword, $description);
    
  • is_spam_contentsをtitle/bodyでひとまとめに
  • isupam, isutarへの接続をkeepalive

といったあたり。このへんをやって11:30ごろ5262点で暫定2位の状態で最初の作戦会議の開催。

11:30

スコア: 5262
第一回作戦会議。アクセスログの解析はできていて、静的ファイル配信とトップがとにかく遅いというのを確認。

  • cssのnginx serve
  • isutarをisudaに吸収
  • gzip_static

をまずはやりましょうとなる。キーワードリンク作成のhtmlifyが本丸でしょうという話はしたけどこの時点でこれについての具体的な解決策はなし。

12:07

isutarのisudaへの吸収完了。
スコア: 5262->5392
が、スコア上昇は誤差の範囲。既にkeepaliveはしていたのでこの時点では意味のない施策だったんだと思われ。ただし状況が進んでハイトラフィックな状態になると効いてくると思うので問題なし。

12:09

isudaのworker数を20にしてみるとスコアが倍増
スコア: 5392->11090

12:14

static fileのnginx serve
スコア: 11090->10902
うーん、誤差の範囲。
このあとmysqlのindex作成など細かい施策をしばらく繰り返すがたいしたスコア上昇には繋がらなくなってきたため、本丸のhtmlifyの改修に着手。

14:04

スコア: 11090->25048
トップページ表示のときに正規表現の作成がエントリごとに行われていたのを1回に集約

16:17

正規表現とキーワードリストをmemcachedにキャッシュ
スコア: 25048->61473

htmlifyの最適化は2時間以上ずーっと取り組んで着実にスコアはあがっていったしずっとボードの5-6位以内につけてたけどこのころすでに20万点オーバーのチームが現れており、このままじゃ駄目だ…と焦りはじめる。

なにか違うアプローチでブレークスルーをおこさないと勝てない、ということでhtmlごとキャッシュの戦略を実施する方向に転換。

16:59

PlackのsessionをPlack::Middleware::Session::Simpleに置き換え。
https://twitter.com/kazeburo/status/777528869939097600
logoutの処理を

-    $c->env->{'psgix.session'} = {};
+    $c->env->{'psgix.session.options'} = {expire => 1};

にしないとセッションがちゃんと切れずにベンチがfailするのにしばらくはまるが解消。
スコア: 61473->67663
キャッシュするための準備でしかないが、スコアがあがり期待が高まる。

17:03

nginxで$cookie_isuda_sessionがない時だけ

proxy_cache_valid  200 1;

をするようにする。

スコア: 67663->228217

きたー。

で、しばらくもうちょっとスコアあげられないか試したけど誤差の範囲でしか変わりがなかったので17:30ごろにはあとは再起動検証をして終わりにしましょう、となり再起動…

17:38

再起動後1回目

スコア: 18万点台(正確なのはとっておらず)

ん、ちょっとおちたなぁ、mysqlのウォームアップ的なあれだろうか、ともう一度実行することに。

スコア: 30435

え?なんで?何がおきたの?
まったく原因もわからず混乱する一同。そして祈りながらもう一度ベンチマーク実行するも、また数万点台のスコアを叩き出す。
残り時間15分。終わった。俺たちの夏は終わってしまったんやー。
と、泣きそうになりながらもう一度再起動をしてみる…。

17:50

再起動2回目

スコア: 19万点台(正確なのはとっておらず)

よし!なんでかわかんないけど命拾いした!ベストスコアからはおちてるけどこれは予選突破できる数値でしょう。
もうやめよう…と思ったけど、「もう一度走らせてみましょう」というチームメンバー。まじか。止める間もなくエンキューされる。

スコア: 223103 (17:54:14)

なんとその日のベストスコアを更新。そのままフィニッシュ。

感想

最後のはなんだったのかいまだに分からず。終了後にidobataで疑問を呈したりもしたのですが、1秒間のキャッシュというきわどい戦略だったので減点によるブレが大きかったのではないかという推察で終わっています。
エンキューガチャ的なことはなかったと信じたいけど、ちょっとだけもやっとしているので、ベンチの再現環境が提供されたら、いろいろと試してみたいです。

うちがhtmlごと1秒キャッシュというきわどい戦略だったのに対し、他の通過者の感想エントリーを見て回るとhtmlifyの最適化やプリレンダとその効率的なinvalidationなど自分にはできてないことがたくさんあって勉強になるし、これらをちゃんとできるようにならないと本戦は無理だろうなという感じで、2位通過なのにだいぶ厳しい気持ちになっております。

何はともあれ、再びヒカリエでの本戦に参加できることは本当に本当にうれしいです。

songmuさんをはじめ出題者のみなさん、運営者のみなさん、お疲れ様でした。本戦もよろしくお願いいたします。

今度こそ優勝するぞ!

はてなブックマーク - #isucon 6 予選二位で通過しました

#isucon 5 予選、惨敗でした

  • 投稿者: chiba
  • 2015/9/28 月曜日 15:21:37
  • ISUCON

毎年でているISUCONに今年も山形組として参加してきました。

今年もオンライン予選があり、9/26(土)の一日目に参加し結果は最高スコアが3000を少し超えるぐらいで惨敗でした。

簡単に何をしたのかをまとめると

事前作戦会議

チーム数多いしボーダーあがって厳しいことになるだろうしトップ狙うつもりでやらないとだろうなとは思ってます

イチかバチかで飛び道具でも使って普通じゃないことをやらないと勝てないと思い込み
kazeburoさんのこの時のエントリなどを読み込み脳内素振りを繰り返す。

当日

11:00
動作確認、コードリーディング

11:30
apt-get update;apt-get dist-upgrade;apt-get install xxx,xxx,xxx & reboot
diskがroの罠にはまる。解決策はわからず、instance作り直し

12:30
第一回作戦会議

今回もインメモリDBでいけそう

という作戦決定…。
mysqlのデータ量がぎりぎりメモリに載せられそうだしこれはインメモリDB組に対する挑戦状や、とか思ってしまいました…。
ちな、/var/lib/mysql/isucon5q/データ量が2.4Gでメモリが3.6G

12:30-15:00
perlにentriesもcommentsものせようとする。が、ある一定の量をのせるとまったく処理がすすまなくなる。おそらくmysqldが確保するページキャッシュとの食い合い。mysqlテーブル側をROW_FORMAT=COMPRESSEDにしたりbuffer_poolを減らしたり増やしたり、Perl側のデータの持ち方を効率化したりいろいろ試すも最後まで実行できず。これはLLなPerlじゃ無理じゃね…と15時ちょうどに断念。(後日富豪インスタンスサーバーで試し、全部読み込んだらPerlのプロセスのメモリが4G超えました!!)

15:00
第二回作戦会議

王道チューニングで1から再開しましょう

16:30
普通のクエリのチューニングを進めていくものの、上位陣が1万を超えるようになってきて焦り

もうだめぽ…こんなふつうのチューニングじゃ勝てない…

ということで、htmlのキャッシュ生成をやってそれを返すとこまでやらないと駄目だと思い込み、その作業を進め始める。

17:40
userデータ5000件のindex.htmlの用意が終わり、それをキャッシュ更新/参照する仕組みでスコア1200ぐらい

18:30
POST時にキャッシュ更新してて3秒にまにあわないから途中でやめてあとはinvalidateだけしていたのをなんとかしないと…そもそもindexの作成のコストがまだクエリチューニングが終わってなくて高すぎる、でも時間ない、ということでPOST時にキャッシュ更新はやめてinvalidateだけするようにしたらスコア3000ちょっと超え、その後悪あがきで/friendsのクエリチューニングなどを始めるもそのままフィニッシュ

最終形のコード

感想

飛び道具(今回の場合インメモリDB)の使いみちをきちんと判断できるようになるべきだったなというのが最大の反省点です。
GOで本文データの持ち方を工夫しながら実施して予選突破した方もいたようですしもうちょっとやり方はあったなぁというのもあります。

ISUCON、初期スコアの100倍、200倍にしないと勝てないみたいなのが通説としてあって、だからそれをやってることってめちゃくちゃすごいことなんだと思いがちなんだけど、初期のコードは本当にクソなので、それの100倍でも普通ぐらいのレベルだという学びもありました。後半も、王道といいつつhtmlキャッシュ作成というキテレツなアイデアに執着しており、そんなことは後にしてまずはシンプルにクエリチューニングを進めるべきだし、結局キャッシュ更新速度のためにもそれは必要だった。

毎回本戦に参加していたのもあって思った以上に悔しい気持ちで、夜どうしても寝れなくて昨夜、まだベンチマークもないのに一人反省会で時間があったらやれた後半のチューニングを進めたりしました。githubにあげてます。基本的にほとんどのページでhtmlをそのまま帰すだけの構成になってます。たぶんバグがまだあるけど通ればトップチームに近いかそれ以上の数値がでるんじゃないかなぁ…。

いろいろやれることは多くて非常に面白い問題ではありました。

本戦にいけなくて本当に悔しいですが、来年も、、、あるのかな、あればもちろん参加したいです。

今回も出題チームの皆様は本当に大変そうで、しかし見事にISUCONの予選を成立させており、素晴らしいとしか言いようがないです。本当に感謝です。
あわせて、主催・共催のLINE、Treasure Data、テコラス、Googleの皆様、ありがとうございました。

はてなブックマーク - #isucon 5 予選、惨敗でした

YAPC::Asia Tokyo 2015に参加してきました

  • 投稿者: chiba
  • 2015/8/24 月曜日 3:01:10
  • perl

8月20日から3日間にわたって東京ビッグサイトで開催されたYAPC::Asia Tokyo 2015に参加してきました。

2012年にスピーカーで参加してから、2回連続で足が遠のいてしまっていましたが、やはり参加すると刺激をうけてよいものですね。

3年前の自分のトークのようなPerl製の(モジュール|プロダクト)名がタイトルに入っているトークはほとんどなくて(あ、LTではcpmがありましたね!)何とも言えないわびしい気持ちになったりもしましたが、その多様性を受け入れる文化も日本のPerlCommunityの素晴らしさなのかなと思ったりもしたり。自分が参加したトークの中ではやはりGoの話が多くなっていて、そろそろ手を付けるか…という気分になって帰ってきました。

YAPC::Asia、lestrratさん(JPA?)が主催するものとしては10回目の今回で最後とのことで、いままで主催されてきたmiyagawaさんTAKESAKOさんlestrratさん941さんyusukebeさんによる【特別企画】YAPCあるあるもみてきました。自分は2007年からの参加ですが、過去のすべてのトークで一番印象に残っているのは、2009年のPSGI – Perl Server Gateway Interfaceです。もともと別の内容のトークが予定されていた枠を変更して発表の数日前に誕生したばかりのPSGIとPlackの紹介を、miyagawaさんとtokuhiromさんがライブコーディングも混じえながら行うというものでした。その後PSGI/Plackは驚くべき速度で普及しましたが、YAPC::Asiaという場がその普及の役割の一翼を担ったことは間違いないでしょう。

なにはともあれ、何年にもわたり主催されてきたlestrratさんはじめ、スタッフのみなさま、本当にありがとうございました!

はてなブックマーク - YAPC::Asia Tokyo 2015に参加してきました

#isucon 4 本選10位で惨敗でした

  • 投稿者: chiba
  • 2014/11/11 火曜日 6:27:48
  • ISUCON

ISUCON4本戦に毎度おなじみ山形組で参加してきました。結果は既報の通り、われわれは8千点前後の団子状態から抜け出すことはできず、60倍以上のスコアを叩き出したLINE選抜チームが連覇となりました。おめでとうございます。

ISUCON2で2位を取って以来、ISUCON3で5位、そして今回10位と順位を下げ続けており、年々高まる参加者のレベルが恐ろしい限りです。

やったこと

  • redisを落として本当のインメモリDBアプリ化(aサーバ)
    「来年、もう一度来て下さい、本当のインメモリDBアプリで優勝させますよ」
  • slot-IDベースでのnginxによる3台のサーバへの動画postの振り分け

    • ad-IDはaサーバのアプリに問い合わせて発番した上で動画ファイル保存
  • asset-URLをあらかじめslot-IDベースで3台のサーバのアドレスに分散

    • nginxからmp4を直接serve
  • –hostsは3台のPrivateアドレス指定。

    • 当初Globalアドレスでベンチが通らず、運営からPrivateアドレスを使うようアナウンスが出てた覚え

やれなかったこと

Plack::Handler::Nginx化
 高rps化しなかったのでやっても意味はなかった

感想

これから出題者側による詳細の講評があると思うのでそれを見てみないと最終的な判断はできないとは思いますが、優勝チームのkazeburoさんのエントリを読む限りでは、ベンチマーククライアントが特殊すぎる状況を模倣してるように見受けられます。
いつもやっていることを当たり前にやることでスコアを伸ばさせたかったんなら、redisからLast-Modifiedを付けずに動画を配信しているところから、ファイル化していつものようにnginx等のwebサーバに配信を任せて、Last-Modifiedが付いた時点で、クライアントはキャッシュするべきだった。
もちろん、Cache-Control(max-age)/Expires をつけることはより良いことだし一足飛びにその設定をする場合もあるだろうけど、普通は狙う効果が違って、これは304すら無くす場合に設定するものです。
実はCDN経由でデフォルトのmax-ageが0でした~という話もあるようだけど、サーバのIPアドレス直でアクセスさせておいてそれはかなり苦しいし、もし特殊なip routingを駆使してそれを実現しているのであればそれこそいつもやってることを当たり前にやってもしょうがない話になってしまう。前任者はトラックにでもはねられたのだろうか。
ISUCONの面白さは、一般に存在する”問題”が散りばめられていて、経験者はいつもやっていることが功を奏し、そうでないものは今後に活かせる教訓を得られるということだと僕は思っています。ISUCONにしか存在しない”問題”が作成され、それが解けたか解けないかで出題者が出場者に勝った負けたと騒ぐイベントだったのかなぁと。

というわけでたっぷり負け惜しみを書きました。

来年も開催されるとのことですが、予選を含めた過去のISUCON本番計測のすべてにおいて完走というちっぽけな記録が継続中なので来年も最低限そこは死守しつつリベンジします。もう負け惜しみを書きたくないです。

出題を担当されたクックパッドの皆様、主催/共催の、LINE、テコラスの皆様ありがとうございました。

はてなブックマーク - #isucon 4 本選10位で惨敗でした

#isucon 4 予選参加してきました

  • 投稿者: chiba
  • 2014/9/29 月曜日 18:53:44
  • ISUCON

毎年でているISUCONに今年も山形組として参加してきました。

今年もオンライン予選があり、9/27の一日目に参加し結果は暫定で7位でAMI審査に問題がなければほぼ予選通過はすると思われます。

で、今年は何をやったか、というとあいも変わらず去年と同じことをしておりました。去年と同じ方式でかくと

やったこと

静的ファイルはnginx serve
アプリ全書き換え
 1fileなPSGI
 データはすべてオンメモリ
 永続化はテキストファイルへ追記
nginx embedded perl + Plack::Handler::Nginx ←NEW!

最終形の構成をgithubにおいときました。

やれなかったこと

無し

最終提出スコア

–workload 8で
62145

コンテスト中の流れ

事前にHDD8G メモリ15Gのm3.xlargeインスタンスだとわかっていたので、それがボトルネックの解消につながるかは別として、インメモリDBアプリにすることは可能だとわかっていました。
で、蓋をあけてみたらいままでで最も簡単な内容のアプリだったため、いつもの通り全書き換えしつつのインメモリDBアプリをFeersumで動かす方針に決定。
もう一人のメンバーにクエリ書き換え等の王道チューニングを進めてもらいつつ、14:10ごろに書き換えとバグとりが完了。workloadの調整などをおこない、14:20ごろにworkload:5 58000ぐらいのスコアで提出。この時点では2位。nginxによるキャッシュをいれて、14:28ごろ、workload:6 60806で提出。1位。
この時のチャットログ

9/27 14:28 
workload:6
tag:benchmarker type:score      success:281500  fail:0  score:60806
で提出完了
9/27 14:28
もうほぼ限界だとおもう
...中略...
9/27 14:31
もう10チーム以上6万台の誤差勝負とかにならない限りは大丈夫だとおもう

というわけでしばらくのんびりしていたら、いつのまにか7万点台のスコアを叩き出すチームが現れ…。

16:13
うおおおおおおおおおおおおおお
16:13
7万ごえきた
16:13
YABAI!
16:18
まじか…
16:21
nginx embededやるか…

と、この時点では、nginx->feersumというリバースプロキシ構成だったので、nginx embeded perlで完全に1プロセスにしてしまうことに。
で、nginxのビルドやPlack::Handler::Nginx自体への修正なども行い、新たなバグとも戦いつつ

17:47
tag:benchmarker type:score      success:287690  fail:0  score:62145

で、フィニッシュとなりました。もっとスコアが上がって7万点台に届くとおもっていたので、トップの人はどうやってるのか謎すぎる状態での終了でした。
結果も更に順位が落ちて7位となっていました。

感想

で、workload解法があったということだったのですが、まあこういうことも含め競技だとは思っていますので結果には納得していますし、その後の運営の対応も素晴らしいものでよかったと思っています。

出題内容は、過去のパターンと比較しても優しすぎて、参加人数が増えている今となっては上位スコアが団子状態になってしまってるんじゃないかなぁと。いろいろな制約の上での出題だと思いますので、難しいところではあるとは思いますが。

本戦はもちろんそういったことにはならないと思っていますので、(出場できるであれば)準備を万全にして臨みたいと思っています。

なにはともあれ、出題されたクックパッドの皆様、主催・共催のLINE、DATAHOTEL、Amazonの皆様、ありがとうございました。
本戦の出場が正式に決定しましたら、その際はまたどうぞよろしくお願いいたします。

はてなブックマーク - #isucon 4 予選参加してきました

1 2 3 4 5 6 9

ホーム

検索
フィード
メタ情報

ページの上部に戻る