by shigemk2

当面は技術的なことしか書かない

アドテク×Scala×パフォーマンスチューニング #adtech_scala

勉強会

パフォーマンス改善の心構えと勘所

Demand Side Scienceの紹介

http://demand-side-science.jp/blog/

DSPの開発をやっていた

SSPに対して入札を行う仕組み

オプトグループに参入 unisを開発

ロジックを使って動的に広告を生成

ベンチャーマインドとオプトグループ、サイエンスを軸にする

みんながハッピーになれる世界を目指して

構成

RDMS NOSQL ログストレージなど

JSのチューニングは割愛

パフォーマンス・チューニング概論

システムの課題を解消

  • 高負荷時のアプリケーション挙動
  • レイテンシー(応答時間)が悪化
  • バッチ処理の所要時間が目標を超過
  • 開発ツールの動作が遅い

インフラコストの削減

  • アドテク分野では重要 コストが肥大しがち
  • 大量トラフィック、厳しい応答性能 データベース

目的を見失ってはいけない

  • インフラを増やすだけでいっていうわけではない

  • 目的を達成したらある程度手を引く

  • メトリクスの測定

  • ボトルネックの特定
  • 仮設を立てて調整

プログラムの処理にかかる時間の80%はコード全体の20％の部分を占める パレートの法則

ボトルネックの傾向はDBになりがち

正しい実装さえしていればI/Oバウンドが問題になるのではないか

I/Oって何

メモリ ディスク ネットワーク

パケット転送が一番遅い→CPU命令1回に1秒かかるのならば、パケット転送は5年かかる(日本と西海岸)

  • 100万回のシークが発生すると、2.5hくらいかかる
  • 10GBのファイル1個で1回のシークで済む

JVMパフォーマンストライアングル

http://mogproject.blogspot.jp/2012/06/performance-triangle-for-jvm.html

要件定義

性能要件について関係者の合意を得る

  • 想定ユーザーID数
  • ブラウザ数
  • 広告配信量
  • 目標応答時間
  • 増加計画
  • トラッカー受信量
  • ユニーク数の集計は必要か
  • 売上計画(シーズンにあわせたい)

これらのアーキテクチャの設計に重要

方式設計

  • アーキテクチャ

  • フレームワーク

  • 並行プログラミングモデルの設計

  • ブロッキングをいかに減らすか

環境設計

  • データベース設計(ルックアップ回数)
  • メモリ使用量
  • DB単体の性能

環境構築 プログラミング

時期尚早な最適化は諸悪の根源 vs 効率性は無視できない

  • 線形より悪いアルゴリズムはできるだけ避ける
  • 推測しないで計測する

sbt-jmh

アノテーションをつけて計測する

スループットが表示される(大きければよい)

Scala最適化の例

  • Scalaコレクションを正しく使う
  • 関数呼び出しよりも再帰を使う

ScalaBlitz

http://scala-blitz.github.io/

システムテスト

性能テスト

  • 単体負荷テスト
  • シナリオ負荷テスト
  • エージングテスト(連続稼働)

シンプルなベンチマークツール

Gatling

Scalaで書かれたテストツール

JMeterの時代は終わった(GUIでシナリオを作るのはつらい)

テストとチューニング→運用

ログ出力 異常検知 トレンド可視化

これらをやっていくのが安定稼働への第一歩

本番環境でGCログは出そうぜ

JVMの運用

標準出力/入力はログにとっておく

http://www.slf4j.org/

可視化

最後に

それでも行き詰まったら、C++