[T2-302] Visual Studio による徹底!! アプリケーション チューニング & データベース リファクタリング

日時

• 2009/08/26（水）18:25-19:35

概要

スピーカー

株式会社アークウェイ 黒石 高広

株式会社アークウェイ 丸山 和秀

資料

• 資料URL：20090826_T2-302.pdf【ADrive.comに置いてあります】

資料には出てこなかった口頭でのフォロー内容

1. Visual Studio 2008 Development Edition と Database Editionは、内容はかなり異なるが、今後統合されるという話があったので、今回のセッションでは両方題材とした。
2. 最近あったパフォーマンスチューニングの事例を3件取り上げた。
   • 事例の内容については資料を参照。
3. 事例#1の対処方法
   • 200万件の案件を処理する前段階に別プログラムを経由させて、並列処理を実施するようにした。
   • [教訓] 実装の技術をVBAに決定する前に、性能が発揮出来るか議論していれば、このケースは回避出来た。
4. 事例#2の対処方法
   • SOCKET通信を使って自前でFTP転送を行うプログラムがあり、その中にDNS参照する記述があった。
     • テスト環境にはDNSサーバがあったが、本番環境にはDNSサーバがなかった。
   • DNS参照のコードをやめて、IPアドレスを直接入力した。
   • [教訓] コードレビューが出来る人がいなかった
   • [教訓] 性能を上げるには、コードを読む力が必要。
5. 事例#3の対処方法
   • 解決するまでに1ヶ月以上かかった。
   • Development Editionのプロファイラが役に立った。
     • それまではまったくわからなかった。
   • 共通のライブラリの中で呼ばれている処理だったので、実装者はまったく意識してなかった。
6. 性能問題には2つのパターンがある
   1. 処理速度（詳細は資料参照）
      • アプリケーションとしてもダメダメなパターン
   2. スループット（詳細は資料参照）
   • 上記2パターンで、パフォーマンスチューニングのやり方が変わる
     • どっちのパターンなのか、まず見極める必要がある
7. パフォーマンスチューニングは、1つ問題を解決しても終わったことにはならない。
   • 何度かパフォーマンスチューニングを繰り返す必要がある。
   • 1週間か2週間は早くてもかかる。
   • スケジュールには、あらかじめ2週間は確保しておきたい。
8. インフラの性能問題は、プロジェクト終盤に改善することは不可能。
   • すでにインフラは確定されていて、変更できないことが多いから。
9. パフォーマンスチューニングは、すでに確定されているインフラ上という条件で行う必要がある。
10. ウィルススキャンソフトの影響を受けてパフォーマンスが落ちていることが多いので、まっさきに疑った方が良い。
11. SQLが複雑で遅い場合、SQLサーバのプロファイラ機能を組み合わせて検証すると、クエリのレベルまで分析することが可能。
12. スループットの問題は、どこが問題なのかを探すところからなので、消去法で可能性を潰すため、非常に時間がかかる。
13. パフォーマンスを測定するときは、Visual Studio .Netのビルドの種類を「Release」ビルドにすること
    • 「Debug」だと、余計な情報が入るので正確なプロファイリングが出来ない為
14. Visual Studio の Database Editionはわかりづらい。
    • Databaseの単体テスト機能がある！
    • Databaseのリファクタリングまである！（ストアドプロシージャの名称変更など）
    • 本番環境とステージング環境のスキーマの比較が可能