パフォーマンスチューニングセッション、Explained

Article
02/12/2009

昨夜はガッツリ寝ました、ロバートです。
でも、その分、今朝は4時起床… なんでだろう。

さて、本日のブログでは、昨日のセッションの内容をスライド込みで解説します。

※ 当たり前なことしか話していませんので、変にツッコミ入れんといて下さい ( >_<)

タイトルは、VSTS 2008 によるパフォーマンスチューニング。
先日のポストでも言った通り、MSC 2008 の時とネタは同じです。PPT さえ、同じです。
違い？「～ & テスト」と書いてあるか否か。後、今回の話は「実践的」と言う言葉は一度も出していない。
それくらいです w

アジェンダも大差ないです。ただ、今回は極力、製品の話は減らしたと言うことですね。

今回は、冒頭でこんなことを言いました。
パフォーマンスチューニングとは、決して華やかさのあるものではなく、むしろ地味なんです。
地味な作業ほど、大事なんです。怠ってはいけないんです。

デベロッパーの皆さんからしたら、「んなこと分かってるよ」と言うことばかりだったと思うのですが…
「分かっている」と言うのと「やっている」と言うのは大違い。
意外と理解していても、実施されていないベストプラクティスなことって、沢山あったりしません？

細かいことが沢山… でも、「ちりも積もれば山になる」ですよね？
「山」はイイ方向にも、悪い方向にも積もります。

パフォーマンスチューニングのお話をするにあたって、必ず見せるスライドが以下の二つ:

「パフォーマンス」のお話って、意外と難しいんです。
なぜなら、パフォーマンスは「体感」することが主だから… 数値だけで表わせるものではなくて、実は一番のパフォーマンスインジケーターって、ユーザーの感覚なんですよね？

アプリケーションを起動して「遅い」と感じるか否か。
人によって、全然違う。
アプリケーションを複数使って、「重い」と感じるか否か。
これもまた、人それぞれの感覚。

でも、実際にフィジカルな世界で理解できることとして、システムに対する負荷が増えれば、そのシステムのパフォーマンスは低下すると言う当たり前な事実。
どうやってそれを認識するか？どうやって数値化するか？
リソースモニターやパフォーマンスモニターを利用したことは、ありますよね？

Windows のシステムツールに含まれる、このようなツールを利用してパフォーマンスを計測することって結構あると思います。
そして、パフォーマンスチューニングとは、負荷になっている部分を特定して、その負荷を軽減するなり分散するなりしていくこと… そして、それらをフィジカルレイヤー (ハードウェア) ではなく、アプリケーションレイヤー (ソフトウェアのコードレベル) で対応していくこと。

でも、パフォーマンスチューニングって、ただ当てずっぽうに「このコードをオプティマイズしよう！」と言ってできることでもない。
また、細かい一部分だけをいじって実現できることでもない。
アプリケーション全体を通して実施するにしても、時間も工数も多くなる一方で、効率的ではない…

じゃ、どうすれば良い？

パフォーマンスフレームワークと言うのは、開発中に設定するべき「パフォーマンス目標値」を決めるために利用するフレームワーク。
一種の考え方ですね。

パフォーマンス目標値っていうのは、要は、アプリケーションが収まるべきパフォーマンス値ですよね。

それは、例えば**応答時間 (レスポンスタイム)** であったり、スループット (処理能力) であったりします。
そして、このご時世では、新しいハードウェアも今までのように購入されない… インフラストラクチャーの変更も、そうも多くはできない。
**リソース利用とは正にそこであって、既存のサーバーやネットワークリソースをどのように活用するか…そのリソース内でチャントしたパフォーマンスを出せるアプリケーションを作れるかを考える項目になります。
また、ワークロード**では、大体のユーザー数であったり、データ量、トランザクション量などを検討していく項目になります。

もちろん、アプリケーションによってはこれらの項目を見るのが正しいとは限らない…
もしかしたら、他にもパフォーマンス目標値を設定する項目として考えるところはあるのかも知れない。

でも、パフォーマンスの目標値を設定することが大事であって、それに向かって開発もテストも実施していくのが妥当なんだと思います。

冒頭でも言った通り、地味な作業なんですよ。
でも、とても大事なことなんです。

そして、設定することだけが重要なのではなく、設定したパフォーマンス目標値にチャント到達しているか、プロアクティブにテスト・計測していくことが大事です。プロアクティブ (Proactive) は、ニキビの薬じゃないっすよ。ことを 「進んで実行する」 と言う意味です。

テストの世界では、開発中のバグを発見するのに時間がかかればかかるほど、その開発プロジェクトのコストが Exponentially に急増すると言う風に言われているじゃないですか？
それと全く同じです。パフォーマンスについてだって、後行程まで待つにつれ、そのパフォーマンスを取り戻そうとするのは至難な技になり、最悪の事態にはプロジェクトを白紙に戻してしまう恐れがあります。
また、パフォーマンスの悪いアプリケーションを展開してしまう、もしくは納品してしまう… 「ハードウェアの増強で補って下さい」なんて今のご時世で言えませんよね？言ったところで、ハードウェアのコストが上がってしまう… そして、当然のようにサポートのコストも上がってしまう。

踏んだり蹴ったりな状態になってしまいます。

プロアクティブにテストを実行して、パフォーマンスの計測をすること…これは、不要なコストを防ぐことにもつながるんです。
勿論、それだけではなく、随時テスト(計測) → チューニング → テスト (計測) → チューニングといった反復作業になるので、「慣れ」ができる。「ベストプラクティス」だってできあがっていく。そして、なにより大きなロールバックが発生することが基本的になくなる。

言いかえるとどういうこと？メリットが多いんです。

**成果物**として「パフォーマンスの高いアプリケーション」を作り上げることができ… **プロアクティブにテスティングを実行することにより「全体的なコスト削減」を図ることができ、アプリケーションのライフサイクルに準じて開発を実行**することにより、「開発効率の向上」をも図ることが可能になります。

そしてそれは「お客様満足度アップ」にも「生産性アップ」にも繋がり、これは、言い換えれば、製品の信頼性やイメージアップにも貢献する。

ここでの僕から、デベロッパーの皆さんへのメッセージはこれ。

1) 発生しなかったコストは、ポテンシャルコストとして認識して下さい。そのコストが発生しなかった＝その分のコスト削減をしているんです。
→ 要は、「コスト削減」と、脳なしのように、それさえ言えば良いような感じになってしまったこのご時世で…「我々は、こう言う取組をすることによって、コスト削減に貢献しています」と胸を張って言えます！と言うこと。伝わらないようであれば、「じゃ、パフォーマンステストとかするのやめます…どうなっても知りませんが」くらいな強気に出て良いと思うんですけど (僕だけかな？ www)

2) コスト削減にも貢献し、パフォーマンス高いアプリケーションを作っていく… お客様に満足してもらい、それはブランド力にもなる。会社の信頼性も強化される。プラスのことに多く貢献するデベロッパーの皆さん。皆さんはコストなんかじゃありません。アセット (資産) なんです！
→ 開発者とかエンジニアって、コストと言う風に見られがちですが、決してそんなことはない。「コスト削減」だからと言ってデベロッパーを削るなんて、信じられない。当然、アセットとして見れないデベロッパーは切られても仕方がないですけど (僕、わりとドライです)。
でも、皆さん、地味でもやるべきことをやっているのであれば…絶対コストだなんて言わせてはいけませんよ。

と、こんな話をしているうちに35分以上が経過…残り時間10分弱で Visual Studio Team System 2008 のお話を…
なんて状態になっていたんですね (汗)
ムリ、ムリ、ムリ。

でも、僕も Visual Studio Team System のプロダクトマネージャですからね。
Visual Studio Team System 2008 Development Edition のプロファイラ機能をデモさせてもらいました。

サンプリング (Sampling) で実施するパフォーマンステストと、インストルメンテーション (Instrumentation) で実施するパフォーマンステストをお見せしました。そして、チューニングを実施した後に再計測をして、どれだけのパフォーマンスブースとがあったかを見ていただきました。

「分析」メニューから「パフォーマンスウィザードの起動」に行くと、3ステップ (正確には2ステップ＋完了) ウィザードを起動することができます。