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

2010/07/20

日時

  • 2009/08/26(水)18:25-19:35

概要

スピーカー

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

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

資料

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

  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のリファクタリングまである!(ストアドプロシージャの名称変更など)
    • 本番環境とステージング環境のスキーマの比較が可能

-未分類