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

昨夜はガッツリ寝ました、ロバートです。
でも、その分、今朝は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ステップ＋完了) ウィザードを起動することができます。

プロファイルする対象となるアプリケーションをドロップ メニューから選択して、サンプリングもしくはインストルメンテーションでのパフォーマンス計測をするかを選び、【完了】

…それだけで準備完了。

あとは、「パフォーマンスを使用して起動」のボタンをクリックするだけ。
アプリケーションを一通り動かして、落とす。

そうすると、レポートが出てくる: サンプリング (左) と、インストルメンテーション (右) ではテスト時に採取してくるデータ量が違うんですが、アプリケーションの種類によってそこは使い分けて下さいね！

概要のビュー以外にも、勿論分析データの見方は色々とあります。

コール ツリーのビューでは、**ホット パス**を利用すれば問題の関数にまっすぐ飛べます。そして、そこから右クリックで「ソースの表示」を選択すればソースコードに行くことができるので、これまた便利♪

こんなビューも。
そして、肝心なデータの比較…

上に赤い矢印は、悪化した箇所
下に緑な矢印は、改善された箇所

そして、このデータを Excel などに取り入れて、グラフ化してもレポートとしては良いかも知れないですね。

 

ザックリと、こんな話をしていた訳でございます。
いかがでしょうか？

Comments

• Anonymous
  March 15, 2009
  前回のエントリーでは「疑問」から、自分なりの「なるほど」を見つけてみましたが、「自由度の多い」そして「選択肢の多い」現代の開発現場や技術市場においてどんなことをしていくべきなんだろうと考えてみた時、以前ご紹介させていただきましたパフォーマンス