golang.tokyo #3 にブログ枠で参加した #golangtokyo
Intro
すみません、超雑なメモ書きです
ぶっちゃけブログ枠が空いていたので無理やり参加した感じです🙇
訂正の必要がある箇所がありましたらお知らせいただけると幸いです
Accelerating real applications in Go
Accelerating real applications in Go
久保達彦(id: cubicdaiya) / 株式会社メルカリ
遅れてしまって久保さんのトークは後半しか聞けませんでした 🙇
- Worker の数だけ gorutine を起動する
ブロッキングしないための工夫
- メトリックを取る
- channel の使用量は len() を使うと取れる
APNS
- Worker の数 + pusher pool の数だけ push を送れるようになった
既存のアプリケーションに golang で proxy server を挟んで性能を出す。golang にはマッチしている
感想
- gaurun は以前から mercari さんで production 投入されている push 基盤なので相当ノウハウが溜まっていそうです
PERFORMANCE OPTIMIZATIONS
Carlo Alberto Ferraris / 楽天株式会社
https://slides.com/cafxx/perf-opts-devops/live
performance / Optimization
Theory /= practice
価値を共有しよう
最適化には最初に計測
あなた (開発者) のコストはサーバーより高い
12factor.net 日本語もあるよ
冗長化すれば安定する
しかし冗長化は簡単じゃない
自動的にリカバーしよう
全部を自動化しようとは言わない
基本は挑戦すること
KISS (Keep It Simple, Stupid)
コードを読む時間は書く時間の10倍にもなる
可読性とメンテナンス性を最適化するべき
読みにくい早いコードより読みやすい遅いコードの方が良い。コンピューターリソースの方が開発者より安いのだから
単一の目的
循環参照はダメ
分離しよう
可視化しよう
メトリックス、ログを見る
アラートは最後の結果を出すべき
まとめ
シンプルに、すべてを計測し、問題を最適化する
Q: Slack が好きで使ってるんだけど、どんなインターフェースを推奨します?
A: 状態を監視するのにチャットを使ったりする (的な…?その後聞き取れませんでした…)
感想
- golang に限らず全ての開発現場に当てはまるようなお話。back to basic な感じで身の引き締まる想いでした
LT
Streamの扱い方
辻 純平 / AWA株式会社
一度 []bytes に変換して decode するコードをよく見かける
これは不要
Stream を使うメリット
- メモリの効率化
- 標準パッケージの多くがサポート
実際に計測してもメリットを表している
実装例
感想
実際の経験からの有用な Tips
deeeet さんの tweet も有用
なぜ io.Reader/io.Writerを使うべきかは Ben Johnsonの https://t.co/Td9WAB39ip がめちゃ詳しいです #golangtokyo
— Taichi Nakashima (@deeeet) 2017年1月26日
やってみるとわかるけどgo bench -benchmemでメモリのアローケーションを可視化しながらベンチしてるとアロケーション減らすだけで大きな改善が見られる.io.Reader/io.Streamとかはその一歩でどれだけ大事かわかると思う #golangtokyo
— Taichi Nakashima (@deeeet) 2017年1月26日
Database migration
konboi カヤック
Github ランキング上位の db migration tool は Rails style
Rails 方式
メリット
アプリケーションと同じ言語
デメリット
DSL を覚えるコスト コンフリクトしやすい
git-schemalex Schema lex を使った migration tool GitHub - soh335/git-schemalex: database migration tool for mysql schema is managed via git
差分を見て SQL を吐いてくれる。その際にハッシュ値が更新される
感想
- 某所 Slack にてこの話題を小耳に挟んでいたので、ちょっと聞き流してしまいました💦
database/sql と connecton
Talos208
database/sql
ドキュメントに connection を Close することは滅多にない、使いまわすというような事が書いてある
connection pool の話
接続数制限の API
- 現場で起こった問題
- connection が死んでいても気づけなかった
- 1.6 で導入された DB.SetConnMaxLifetime() で解決した
感想
- この辺の問題でしょうかね? github.com
懇親会
サイバーエージェント様ありがとうございました! (dictav さんの tweet を拝借 🙏 )
遅くなってごめんなさい。
— PLEASE GIVE ME A JOB (@dictav) 2017年1月27日
サイバーエージェントさん、ありがとうございました!#golangtokyo pic.twitter.com/RFsv2EzTTp