Skip to content

MS_PerformanceProblemPoints

Jump to bottom
nishi_74322014 edited this page Aug 3, 2026 · 1 revision

性能問題のポイント

概要

性能設計のポイントをまとめる（体系はコチラのほうが上手くまとまっている）。

サーバ マシン

サーバ負荷分散（垂直分散）

垂直分散

２層 -> ３層化

WebサーバとDBサーバの分離

帳票出力処理

帳票出力処理を専用の非同期処理サーバに切り出す

非同期処理

帳票出力処理や、その他のバッチ処理などを分離して外出しにする。

DBサーバ

DBMSをインストールしたサーバーを分離して外出しにする。

リソース

CPU（コア）数

物理メモリ搭載量

  • アプリケーションの仮想アドレス空間（32bit、64bit、/3Gスイッチなどで変わる）

補足（最新化）: /3G スイッチや AWE は 32bit 時代の回避策で、 現行の 64bit Windows / SQL Server では不要（AWE は SQL Server 2012 以降で廃止済み）。

ディスク性能

ディスク、ディスク コントローラ性能と、RAID（MS_RAID.md）構成など。

NIC性能

NICの帯域幅、NICチーミングによる帯域幅増、負荷分散。

ネットワーク機器

ネットワーク負荷分散（水平分散）

Webサーバ

NLB（MS_NLB.md）負荷分散

DBサーバ

シャーディング（水平的パーティション分割）（Elastic Scale, Elastic Database Pool: MS_ElasticScaleAndElasticDatabasePool.md）

ネットワーク帯域幅

ネットワーク品質

  • べスト エフォート型サービスではサービスの品質(QoS)の保証がない。
  • 最低限の帯域幅、パケットロス率などに注意する。
  • PacketShaper等のアプライアンスにより、品質改善することも可能。

ミドルウェア全般

キャッシュ サイズ

  • キャッシュ サイズ（メモリ割り当てサイズ）
  • 他サーバと同居する場合はメモリ割り当てサイズを指定する。

CPUアフィニティ

  • 他サーバと同居する場合はCPUアフィニティ マスクを指定する。

NUMA

NUMAハードウェアで実行する場合、NUMA対応されているか？

DB物理設計（SQL Server）

SQL Server（MS_SQLServer.md）

インデックス設計

インデックス特性を理解し使用すること。（SQL Server のインデックス: MS_SQLServerIndexes.md）

データ圧縮

データを圧縮することにより、

  • CPUリソースを犠牲にIOリソースを削減する。
  • IOボトルネックを解消、一般的に性能は良くなる。

ファイル分割

（SQL Server のファイル・グループ: MS_SQLServerFileGroups.md）

パーティション分割

（SQL Server パーティション分割: MS_SQLServerPartitioning.md）

DBサーバの水平分散

ネットワーク負荷分散（水平分散） > DBサーバを参照。

非正規化の検討

Webサーバ構成

SSL（HTTPS）・HTTP圧縮（ → 必要であればアプライアンス化）

静的コンテンツのキャッシュ（ → 必要であればキャッシュ サーバの導入）

アプリケーションの実装

通信処理の周辺では性能劣化が多いので事前によく検証すると良い。

そもそも遅い通信テクノロジに注意

  • COMの初期化
  • プロセス間、マシン間通信（マーシャリング）など、ブラックボックスのプロトコルは特に注意が必要（LANアナライザなどでシーケンスをチェックすると良い）。

クライアント － サーバ間のラウンド トリップ

冗長なラウンド トリップは、ファサード パターンにより集約する。

  • 3層C/S方式では通信ラウンドトリップや、データの整合性を考慮して、ファサード パターンにより１回のイベント処理に対して、１回のコネクション ＆ トランザクション（ ＝ １回のB層呼び出し）とする。
  • 画面単位でマスタデータ・制御データをロード（ファサード パターン）し、保持するとラウンドトリップを軽減できる（また画面を開き直せば最新のマスタデータ・制御データをロードできる）。

DBアクセスのラウンド トリップの集約方法。

  • 参照時のラウンド トリップを抑止
    • 複数レコードの結果セットとして取得
    • JOINを利用し、結合された結果セットとして取得
  • 更新時のラウンド・トリップを抑止
    • 配列バインドを使用
    • ストアド プロシージャを使用
  • O / Rマップしすぎると性能劣化する。
  • 一覧ページのページング処理を工夫する（方式設計書テンプレートを参照）。

ディスクI/Oボトルネック

ページング

メモリを大量消費して仮想記憶を使い出すと、
サーバ機としては致命的な性能劣化（32bitマシンは要注意）

  • SELECT処理で結果セットを（必要以上に）大量に取得してしまう。
  • フェッチ サイズを指定する。
  • 初めは主キーのみを取得し、以降ページングする。
  • DBのROWNUM機能を活用しページングする（方式設計書テンプレートを参照）。

インデックス スキャン

  • DBの検索処理の性能劣化は型不一致のインデックス スキャン発生などが劣化原因として多い。
  • インデックス スキャンの発生は、DBのトレースを取得するなどして確認する。

UIの性能劣化

Web

  • Sessionの消去し忘れによるメモリ リーク
  • 大容量画面の
    • ネットワーク
      • トラフィック増加
      • ラウンドトリップ増加（AJAX系）
    • DOM要素による性能劣化
      • UI要素のインスタンス化
      • UI要素の操作
  • ASP.NETの例
    • JavaScript多用、JavaScriptを多用するサードパーティ製コントロールによる
      初回ロード処理の遅延（上記のUI要素の操作との関連がある）
    • ViewState（MS_ASPNETViewState.md）の状態保持データ（実体はHidden）によるネットワーク トラフィック増加

RichClient

テスト

単体テスト（プロト、モック評価を含む）

プロト、モックとプロファイラを使用して、
現行方式中のボトルネックなどを確認しておくと良い。

結合テスト

処理時間を出力するログなどを埋め込んでおき、
処理時間の遅いものの原因を調査し、必要に応じて早期対応しておく。

負荷テスト

  • 本番環境に近い構成で組む。ピーク時の見積もり、評価を行う。
  • オンラインの負荷テストの場合、負荷テスト ツールのスクリプトを組み合わせ、
    本番で起き得るシナリオ（トランザクション パターン）をシミュレートする。
  • サーバ リソース消費量はパフォーマンス カウンタ監視を用い、問題がないか確認する。
  • APサーバが２層以上の複雑な構成であるなら、各サーバでの滞留状況も確認する。
  • Microsoft系は自動チューニングが主流なので、パラメタ変更は
    負荷テストの結果（パフォーマンス カウンタ監視）から判断する。

運用関係の性能チェック（設計＆検証）

DB運用関係（SQL Server）

SQL Server の管理（MS_SQLServerAdministration.md）

バッチ処理が時間内に終わるか。

バックアップが時間内に終わるか。

上記DB運用系操作

  • インデックスの統計情報の更新
  • インデックスのデフラグ・再構築
  • データのアーカイブ

障害復旧の時間確認

操作訓練

操作訓練も必要になる。

バックアップ・リストアの時間

フェイル・オーバ、フェイル・バックの時間

ウィルススキャン

（ウィルススキャン）

Tags: 設計のポイント, 性能

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally