isucon

当日の感想解くのに夢中で、全然覚えていないですが、こんな感じでした。 dockerについて Dockerfileがあってdocker剥がそうとして悩む。Dockerfileの中でビルドだけじゃなくて、いろいろやっていて読み解けず混乱していました結局、dockerは使っていないみたいで、そもそもdocker自体が環境にinstallされていなかったのでスルーすることに事前に用意したMakefileやシェル環境の準備微修正で大体上手く動きました計測グッズの投入 alp/slowquery/pprofは事前練習通り、スムーズに入れられて、分析に辿り着けました実際ボトルネックで戸惑うことはそんなになかったです（ボトルネックで迷うようなレベルまで辿り着けなかったともいう tbls tblsでER図を出力しようとしたけど、なぜか上手くいかず、結局mysqlにuserを追加して、出力しました結局外部キーが貼られていないので必要なかったです。schema.sqlファイルをみるだけで十分でした無駄に時間を使ってしまった秘伝のタレなぜか終盤の16時くらいに投入し始めました（始めにやるべきだったなぜかアプリ側のmaxconnectionsを10にしているという、痛恨のミスに後になって気付きました（50くらいにしたかった icon iconが遅いのは計測結果で明らかだったので、iconから手を付けることに ISUCON本に書いてあるMySQLからローカルファイルへの移行が効果的だと判断して、割りとすぐ実装できましたでも、実際細かなミスが発生していて、ベンチマーカーも動いてくれず、進みが悪い時間がかなり長くありましたミスの原因としては、icon_hashを見逃していたことと、ディレクトリ指定をミスっていたところレスポンスのicon_idは何も使っていなかったようですが、0を返したらエラーになったので、uuid返すというよくわからないことをやりました nginxでtry filesで返すようにも設定したけど、あまりスコアには効かなかった気がします etagは存在を忘れてました statistics これもとんでもなく遅いのが初期段階でわかってました典型的なINDEXとN+1の解消が効果的なので、ChatGPTの力を借りながらひたすら実装していきました iconと同時並行で手を付けていましたが、結局落ち着いて取り組めたのが、14時過ぎくらいだった気がします iconの不具合とベンチマーカーが動いてくれない問題があり、あまり集中できなかったですスキーマ変更の投入手段に悩む schema.sqlを書き替えるだけでは反映されないので、別の方法を考える必要がありました当日マニュアルでは、drop database/create databaseして、setup.shを実行すれば、再度構築されると書いてあったので、スキーマ変更後にそれをやればよさそうでしたただ、毎回mysqlにlog inして実行するのは効率が悪く＆isudnsのスキーマがなかった（実際はどこかにあった？）ので、軽く整備しました setup.sh同様にcustom.shとsqlファイルを準備して、goのcmdで実行するようにしましたここで間違えてisudnsの方のdatabaseをdropしてしまい、復活できずに、cloudformationから環境を作り直して、かなり時間とられました DNS 今回の問題の肝だったと思いますが、時間がなく着手できなかったです他のチームの感想みてみると、PowerDNS止めた上で、MySQLではなくインメモリにドメインリストを管理するように自前で実装すればよかった？？サーバー分割について 17過ぎからサーバー分割に着手しました時間もなかったので、1:nginx+app,2:dbで一台あまらせる構成でいいやと判断しました（間違えてpublid ipをhostにしてしまったりしたものの）分割はできました initializeで2台目のsetup.shも呼び出すようにしましたでも、htopでみると、2のmysqlに負荷がかかっているものの、1でもmysqlが使われており、1のCPUが100%に張り付いていましたここでようやくPowerDNSがMySQLに負荷をかけまくっていることに気付きました… DNSだけでも3台目に逃がそうかと思ったけど、時間がなく断念 unix domain socketもやらないと、と思いつつ忘れていました最終的に自分のisupipeがまともに動くレベルになっていて少し感動戦いの記録: https://github.com/EkeMinusYou/isucon13-final 反省点ベンチマーカーの整合性チェックに頼りすぎ実行にラグがあるし、例年から落ちることも予想できたので、実際にサイトを確認するなど別の手段で、チェックすべきでした最初から複数台を見越した準備をするべき 1台でないと解析はしにくいけど、複数台に分割しないとボトルネックに気付けない場合もあるかもしれないまた、どう分割するかも、重要なポイントなので、柔軟に構成を変更できるような、準備をあらかじめ整えるべきでした時間がなくても実際に変更をデプロイする前に、一人レビューするべきでしたケアレスミスでかなり時間を消費してしまったので MySQLのスキーマ変更手段はISUCONの構成に関わらないやり方を用意すべき今回のgo cmdでいいかな？秘伝のタレは一番始めに投入すべきコード読み始めちゃうとなかなかそこに気が回らなくなるのでおわりにめちゃめちゃ楽しかったです！素晴らしい大会を開催頂き本当にありがとうございます！！...