Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISUCON終了後のチームKPT #4

Open
ryosan-470 opened this issue Oct 23, 2017 · 2 comments
Open

ISUCON終了後のチームKPT #4

ryosan-470 opened this issue Oct 23, 2017 · 2 comments

Comments

@ryosan-470
Copy link
Member

ryosan-470 commented Oct 23, 2017

KEEP (よかったね、このまま維持したい)

  • 環境構築がすごい楽だった。SSHとかパスワード気にする必要なかったし (@ryosan-470)
  • デプロイの共通化も楽だった。(@ryosan-470)
  • Goでがんばれた気がする (@ryosan-470)

Problem (問題点)

  • SQLチューニングができなかった (@ryosan-470)
  • 割とどうでもいいことで詰まった。Golangの言語仕様などをきちんと理解できていない。返り値等はエディタのサポートなどを用意しておく必要がありそう。(@ryosan-470)
  • トラフィックが張り付くことを想定すべきだった (@ryosan-470)
  • Goのデバッグ方法をきちんと調べたほうがよい (@ryosan-470)

Try (じゃあどうするか)

  • SQL、MySQLの仕組みを学ぶ (@ryosan-470)
  • Golang自体への理解がまだまだなのでGoのTutorialをやり直す (@ryosan-470)
  • GoでRedis、MySQLの使い方をマスターする (@ryosan-470)
  • delve、GDB等の使い方を調べる (@ryosan-470)
  • N+1問題をきちんと理解する。 (@ryosan-470)
  • HTTP 304等、キャッシュの理解がまだまだ足りない (@ryosan-470)
@tukeJonny
Copy link
Contributor

tukeJonny commented Oct 23, 2017

Keep (よかったね、このまま維持したい)

  • インデックスハリハリはいつも通りのは効いてたようなので、安定して結果出せるようにしたい(@tukeJonny)
  • 秘伝のタレシリーズを用意していたので、confの適用は楽だった(@tukeJonny)
  • よく使うコマンド集、リポジトリにあるソースコードは、結構見たいタイミングでてくるので、本番でもチラチラ見ていた(@tukeJonny)
  • sakasinくんと初対面な気がしなかった

Problem (問題点)

  • アプリ側にほとんど触れられていなかった(SQL周り、Redis周りなどはミドルウェアに関わるところなのである程度貢献できるようにしたい)(@tukeJonny)
  • キャッシュへの理解が足りていなかった(今回の得点源なので、ここは手痛かった。盲点ではあったけれど、今後も得点源になる可能性があるのできっちり把握しておきたい)(@tukeJonny)
  • しょーもない問題で大量に時間を溶かした(重複データの含まれるやつで3時間ぐらい溶かしたり、GOROOT設定しろとか言われて普段やらないことで戸惑ったりと結構溶かした)(@tukeJonny)
  • ensuredepなど、慣れていないことの優先度を下げて取り組んでしまっていた。(@tukeJonny)
  • confは適用できたが、それでも漏れがあった(serviceファイルのLimitNOFILEなど、指定したことで変わった可能性はある。その周りを把握できていなかったのは、他の問題につながる可能性があるので、しっかりしておきたい)(@tukeJonny)
  • ミドルウェア担当として一部分のタスクしかできていなかった(アプリのSQLもそうだが、インフラ構成案、alpやpprof周りも調べた上での総合的な観点でボトルネックを指摘していきたい)(@tukeJonny)
  • マイクロサービスアーキテクチャ環境でのインフラチューニングの練習が足りていなかった(ISUCON6qや他のチームの言っているPixiv ISUCONなどもうちょっとしっかりやっておくべきだったかなと考えている)(@tukeJonny)

Try (じゃあどうするか)

  • 過去問でアプリのミドルウェアに関わるところのコミットを積みまくる。(@tukeJonny)
  • NginxやつかったことはあまりないがVirnishなどの練習をしておく。(@tukeJonny)
  • 「変だな?」と思ったことはとにかく速攻でチームメンバーに共有。視点が足りていないことが原因である場合が多いので、多方面からの意見を聞いたほうが問題の解決が早まり、クリティカルパスを短縮できやすい気がする。(@tukeJonny)
  • GOROOTは、確かに通常設定する分であれば特別設定する必要はないが、「どういう意味を持つ環境変数なのか」、「通常はどこに設定することが多いか」くらいは調べておく。(@tukeJonny)
  • これも、チームメンバーに確認を取ると共に、過去問で設定したことは漏れなくWikiに書き込んでいく。汚くなることを避けたい気持ちになってしまうが、後からまとめればいいだけなので(もちろんなるべく最低限綺麗に書くようにはする)(@tukeJonny)
  • 過去問で実際に俯瞰的に見る経験をひたすら積む。ツール類は一通りすべて逐次確認する(@tukeJonny)
  • 大きな分類での練習量を把握し、偏りがある場合はあまりできていない分類の練習をするようにする。(@tukeJonny)

@ysakasin
Copy link
Member

ysakasin commented Oct 23, 2017

Keep

  • 予選前にチーム練習の回数をそれなりにこなせた
  • Goでのプロファイルが効力を発揮した
  • プロファイラ間の比較でボトルネックの裏付けができた
  • ペアプロ悪くなかった気もする
  • 準備に手間を取られなくて競技に集中できた
  • 施作を適用するごとに着実にポイントアップした
  • Wikiに情報が集まっていてよかった
  • tukeJonny と初対面な気がしなかった
  • 会場が最高だった

Problem

  • 成果が出るまでが長かった
  • 序盤に割と手が空いてしまった。代わりにペアプロしたけども……
  • アプリケーション以外に全くさわれなかった
  • 後半に息切れしてどうでもいいロジックでつまづいた
  • ベンチマークで実際に飛んでくるリクエストの内容を理解してなかった
  • ネットワーク性能などの基本事項を理解していなかった
  • Wikiに情報が集まっているものの若干見辛い
  • N+1改善もどきをしたけど、改善になってたのかよくわからない
  • スコア記録が雑になった
  • 最後の20分くらいで構成を入れ替えたりして下がってしまい危なかった

Try

  • 簡単な統計なんかは自分でSQL叩いて知れるようにする
  • 他のプロファイラも見る
  • アプリ側以外のログの見方を知る
  • ログからベンチ傾向などを抽出する方法を学ぶ
  • クライアント側のコードも読んで、動きを理解する
  • 全体として高速化するだけじゃなく、どこを早くすれば得点が最大化できるかで考える
  • 予選前にWikiを整理する会を開催する
  • 構成を試す期間をきっちり決めて厳守する
  • 当日マニュアルを自分でも一通り目を通す

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants