詳解システムパフォーマンスの読書メモを書いているぞ
miyatakasolarisについて言及しているところが多めなので，vagrantをインストールして，solarisを動かしてみようと画策中
miyatakasolarisはvagrant cloudに公開されているので，行けるかと思ったが，そもそもvagrantをm1 macで動かすのが大変だったのでsolarisについては諦める．
同様の理由でlinuxもvagrantでは諦めて，ubuntuをdockerで動かして，各種コマンドのテスト実行などをやってみることにする
miyatakaまえがきでおすすめされていた通り，13章から読むことにした．実際の問題を例に挙げてBrendan Gregg先生の思考を追うことができ，非常に参考になる．
登場したコマンド，およびキーワードを箇条書きで以下に挙げる
- コマンド
- システムコール
- gtime
- pollsys
- write
- forksys
- fdstat
- fdsync
- キーワード
- 無名ページング
- DFL
- 無名ページング
miyataka第一章 イントロダクション
1.1 システムパフォーマンス
スタック全体(entire stack)という言葉は，アプリケーション環境（アプリケーションサーバー，データベースサーバー，Webサーバー）のみを指すこともあるが，システムパフォーマンス文脈でのスタック全体(entire stack)とは，システムライブラリ，システムコール，カーネルを含む．
1.2 職種
システム管理者，サポートスタッフ，アプリケーションデベロッパー，データベース管理者，Web管理者など，さまざまな職種の人が担うことがある．
パフォーマンスエンジニアという専門の職種が存在する場合もある．専門の職種が存在する場合でも，複数のチームと協働することが必要不可欠
1.3 作業
理想的な作業順は以下．（このように進むことは稀だし，この一部のみ担うこともある）
- パフォーマンスの目標を設定しモデルを作る
- プロトタイプソフトウェア，ハードウェアからパフォーマンス特性をつかむ
- インテグレーション前の開発済みコードのパフォーマンス分析を行う
- ビルドされたソフトウェア，プレリリース，ポストリリースのソフトウェアの非回帰テストを行う
- リリースされたソフトウェアのベンチマーキング・ベンチマーケティングを行う
- ターゲット環境で概念実装テストを行う
- 本番環境で構成を最適化する
- 本番稼働されているソフトウェアをモニタリングする
- パフォーマンス問題を分析する
1.4 視点
視点は２つ
- ワークロード分析（workload analysis）
- リソース分析（resource analysis）
アプリケーション開発者はワークロード分析視点から，システム管理者はリソース分析視点からみることが多いが両方見るとなおよい．
1.5 パフォーマンスエンジニアリングの難しさと面白さ
1.5.1 パフォーマンスは主観的な判断である
たしかにね
1.5.2 システムは複雑である
コンポーネント個別では問題なくても，組み合わせると問題になるケースやエラーの連鎖など
1.5.3 複数のパフォーマンス問題が同時に起きる場合がある
重大な意味を持つ問題を見つけたか，問題の本質を見極めることが重要．
みつけた問題が重大かは自明ではない．だからこそ定量化（quantify）して評価する必要がある．
パフォーマンスを定量化するにはレイテンシ(latency)という指標が役に立つ．
1.6 レイテンシ
レイテンシは待つために使った時間を計測した情報
必要な時に手に入るかはわからない
1.7 動的トレーシング
動的トレーシング(dynamic tracing)によってこれまで取れなかった情報がとれるようになっている．
代表的なツールがDtrace
1.8 クラウドコンピューティング
迅速なスケーリングができるようになったため，厳密なキャパシティプランニングが不要になった．しかし各種仮想化技術が使われており，複数テナントが同一物理サーバーを共有するようになったため，他のテナントからのパフォーマンス影響をマネジメントする必要がでてきた，これをパフォーマンス隔離（performance isolation）という．
1.9 ケーススタディ
ここでは触れない
個人メモ
- 非回帰テストと回帰テストが同じものを指している気がする．
- どちらも調べると，（この文脈ではパフォーマンスを対象に）劣化していないことを確認するためのテストとなる．
miyatakaWIP