ノートに残す内容はあまり無いので別エントリにするか悩んだが、日常の日記に埋もれるよりはまとまってる方が良いかな、と思いエントリを分ける。

6章まで読んだ印象

6章のCPUまで来たので感想など。

5章までが全体的な話で、6章からはそれぞれのリソースとかの話なので、構成としては5章まで読んでおいたらあとは必要に応じて参照出来るようになっている。

一方で5章までだと「詳細は後の章で」ばかりであまり内容が無い。 システマティックな定義が延々と続くのだが、本当にそこまでちゃんと分類するメリットが疑わしく感じられて、いまいち気合が入らない。

OSとかCPUの話も入門的な薄い解説があるのだが、これに意味があるのかいまいち分からない。 ある程度この手の知識は前提とした上で、もっとDTraceの使いこなし方とかそういう方を手厚くしてほしい気もする。

すでに知ってる薄い解説を幅広くえんえんと読むのはあまり有意義には思えないのだが、細かく分類されてて同じ話が分類としての完全性の為に繰り返されるので、知ってる事を飛ばすのが難しい。

そういう訳で効率的に読むのが難しいが、システマティックにまとめようという一貫した姿勢の結果、一歩引いて全体を考えよう、という時に役に立つ本には仕上がってる気がする。 どのように進めるかの方針を考えたりするとか。 通読するよりは、ざっと目を通したあとは、実際に作業する時に目次を眺めながらガイドとして使っていく感じの使い方が良い気がする。 重複が多い事の裏返しとして比較的それぞれの章が独立しているので、それぞれの作業をする時に関連する章だけ読むには良い書き方に思う。

6.6のCPU-Analysisは良い

6.6から具体的なコマンドがいろいろ出てくるが、この章はinformativeだな。 DTraceの例やperfコマンド周辺の情報も勉強になる。 ここまで読まないと具体的な話が出てこないのは本としては辛いなぁ。

7章、メモリを読んだ

6章から先は、しばらく章構成が同じで扱うリソースだけが、CPU、メモリ、ファイルシステム、ディスク、ネットワークと変わっていくという構成。

だから7章のメモリは、6章のCPUから大分どこを読み飛ばしても良いかが判断しやすくなったので、バンバン飛ばす事に。

飛ばし方としてはコマンド名とかパラメータ名などを見て分かる物はそのあとの詳細の部分を読み飛ばす、という感じで読んで行く。

7.5のAnalysisはコマンドや取れる情報についての解説が多くてためになるので、ここを中心に読むのが良さそう（まぁまぁ全部読んだが）。

章としてはCPUに比べると浅い内容だなぁ、という印象。メモリ周りはAndroid開発者だとまぁまぁ細かい事も知ってるのが普通、というのもあるとは思う。

8章 FS, 9章Disk

ファイルシステムとディスクが別の章になってる。モニタリングの仕方が違うからだが、似通った内容も多いので分かる所はバンバン飛ばす。 この辺まで来るとだいぶ安全に読み飛ばせるようになってくる。 真面目に読んでもどうせ頭に入らないので読み飛ばして、使う時に該当箇所を見直す方が良い。

ツール関連はいろいろ勉強になる。へー、こんなのあるんだ、みたいな。

10章のネットワークは読み飛ばし

だいたい何が書いてあるのかは予想出来る節が多かったので、ざっと眺めて読み飛ばし。 この辺は測って実際に遅かったら読めば良かろう。

これで構成要素ごとのパフォーマンスの話は一通り読み終わったことになる。 このあとの章は補足的な内容になるのかな。ここまで良く頑張ったヽ(´ー｀)ノ

11章のクラウドはやや期待はずれ

JoyentとSolarisの話が中心なのが辛い。 ここはさすがにAWSとLinuxとDockerでやって欲しい。 ちょっとEC2の話はあるんだが、さすがに少なすぎだろう。

しかもここは本書執筆時点の2013年からは結構変わった所なのでますます辛い感じがある。 まぁこればっかりは仕方ないか。

12章 ベンチマーク

最初の方を読んでるが、ベンチマーキングはいろいろ難しいんだよ、という事が書いてあって、こんな難しさがあり、あんな難しさもあり、、、とだらだらと書かれている。

内容自体に異論は無いが、だからなんだ、という気もちょっとする。 系統だってる訳でも無く、これで尽くされている訳でも無い。思いついた事が並んでるだけに見える。

また、Benchmark specialはそんな無いと言ってるが、ベンチマークに対してチューニングしてしまっていて実際のパフォーマンスから乖離する事はすごく多いと思う。

本書では良く何をテストしているか理解して対処しろというが、簡単過ぎるベンチマークの問題と思うのだよなぁ。やはりカーネルのビルドとか実際にやる作業の方が良いというパタヘネの主張の方が自分的には納得しやすい。

全体的にベンチマークが人工的な奴が多いよなぁ。ResNetのトレーニングとかLinuxのビルドとかgccのビルドとかいろいろあると思うが、そういう具体的なタスクをやる系統のベンチマークの話があまり無い気がする。 自分はそっちの方を重視しているのだが、著者があまり言及しない理由が知りたいな。 短くて内容がちゃんと理解出来るベンチマークが良い、と言ってるのだから、そうでないベンチマークを良くないと思っていると思うのだが、理由が書いてない。

その後を見てて思うのだが、アプリケーションレベルのベンチマークが想定されてなくて、システムの構成要素、特にハードウェアかそれに類するリソースに関するベンチマークの話しか無い事に気づいた。 System Peformanceというトピックからそれが適切という判断なのかもしれないが、そのむね一言断って欲しいなぁ。 ベンチマーキングは結構関心あるトピックなので期待してしまったではないか。

12章読み終わり。Active Benchmarkingはなかなか勉強になった。 なるほど、こういう感じでやるのは良さそうだな。

13章、ケーススタディ

Redisの遅延を調べる話。予想以上に面白かったし勉強にもなった。 なるほど、これはベテランっぽい、と思う進め方。 こういうのが出来るようになったらいいね。

全体の感想

自分はもっとアプリ開発におけるシステム要因みたいなのに詳しくなる事を期待して読んだのだが、そういう本では無かった。

Unixのサーバーにおけるシステムで、しかもDBとかやることが絞られててパフォーマンスに関わる部分がかなり下の方で探しやすい物の話ばかりだった。 最初からそういう本だと言ってくれればこれはこれで良いと思うのだが、かなり中盤まで読まないとその辺の立ち位置が分からなかったのはいまいち。

また実際に作業する時のガイドとしての使いやすさを優先していて、通読するにはいまいちだった。似てるがちょっと違う視点で同じ話が繰り返され、全体的な構成がわかりにくくすぐ詳細にとらわれて迷子になってしまう。読みにくくて退屈な本だ。

ただ提供されてる情報はなかなか充実してて、役に立ちそう。実際に同じような立場で作業するならすごく役に立つ本だろうし、他の分野の人も読み方を気をつければ多くを得られる本だと思う。

個人的に欲しかったが無かった情報として、モニタリングのノウハウとかが知りたかった。 特にアプリケーション開発でのパフォーマンスのトラッキングは開発が進むほど指標は増えていき、測る対象も問題が発覚したりもはやrelevant じゃなくなったりしていくが、それと時系列にモニタしていく事の矛盾とかをどう解決していくか、みたいな運用の指針みたいなのが欲しかった。そういうのはあまり扱われていない。

アプリの開発の時にDTraceみたいにの使いたいね。iOSとかだと使えないっぽいが、OS X上でヘッドレスな物を作って測ったりは出来るかしら？でもやっぱ出来たら実機で測りたいよなぁ。

アプリでどうメンテ可能にトレースを仕込むか、とかも知りたいが無かった話題だな。

全体としてDTraceやそのほかのツールの威力はすごく説得力を持って示されて、それらを用いてのMethodologyも強力に思えた。提示の仕方は気に食わない所もあるが勉強にはなった気がする。 自分の分野に応用出来るかはちょっと分からないが。