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

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

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

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

スライド1 スライド1

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

スライド2 スライド2

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

 

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

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

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

 

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

スライド4 スライド6

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

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

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

image image

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

スライド7

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

じゃ、どうすれば良い?

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

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

スライド11

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

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

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

 

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

スライド9 スライド10

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

 

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

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

 

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

スライド12

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

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

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

 

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

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

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

 

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

 

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

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

 

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

PerformanceWizard1 arrow01 PerformanceWizard2 arrow01 PerformanceWizard3

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

それだけで準備完了

performanceExplorer

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

ProfilerCapture

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

Sampling01 Instrumentation01

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

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

Instrumentation02

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

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

perfWorse perfImprove

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

image

 

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