Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
概要 †
性能設計のポイントをまとめる。
サーバ マシン †
サーバ負荷分散（垂直分散） †
垂直分散
- ２層 ---> ３層化
- 帳票出力処理
- 非同期処理
- DBサーバ
リソース †
CPU（コア）数 †
物理メモリ搭載量 †
- アプリケーションの仮想アドレス空間（32bit、64bit、/3Gスイッチなどで変わる）
ディスク性能 †
ディスク、ディスク コントローラ性能と、RAID構成など。
NIC性能 †
NICの帯域幅、NICチーミングによる帯域幅増、負荷分散。
ネットワーク機器 †
ネットワーク負荷分散（水平分散） †
Webサーバ †
NLB負荷分散
DBサーバ †
シャーディング（水平的パーティション分割）
ネットワーク帯域幅 †
ネットワーク品質 †
- べスト エフォート型サービスではサービスの品質(QoS)の保証がない。
- 最低減の帯域幅、パケットロス率などに注意する。
- PacketShaper?等のアプライアンスにより、品質改善することも可能。
ミドルウェア全般 †
キャッシュ サイズ †
- キャッシュ サイズ（メモリ割り当てサイズ）
- 他サーバと同居する場合はメモリ割り当てサイズを指定する。
CPUアフィニティ †
- 他サーバと同居する場合はCPUアフィニティ マスクを指定する。
NUMA †
NUMAハードウェアで実行する場合、NUMA対応されているか？
DB物理設計（SQL Server） †
インデックス設計（インデックス特性を理解し使用すること） †
クラスタ化インデックス †
Oracleでは「索引構成表」と呼ぶ。
非クラスタ化インデックス †
所謂インデックス。
カバリング インデックス †
付加列インデックス †
インデックス ビュー †
Oracleでは「マテリアライズド･ビュー」と呼ぶ。
データ圧縮 †
データを圧縮することにより、
- CPUリソースを犠牲にIOリソースを削減する。
- IOボトルネックを解消、一般的に性能は良くなる。
ファイル分割 †
- ファイル グループ（Oracleでは「表領域」と呼ぶ）を使用した簡易RAID（ストライピング相当）
- また、部分的なバックアップ・リストア、段階的なリストアなど、運用系の時間短縮も可能。
パーティション分割 †
主に運用系性能（インデックスのデフラグ・再構築、データのアーカイブ）向上が可能だが、
一部データ アクセス性能（並列クエリ、スキャン局所化、テーブル結合、ロック局所化）も改善。
（インスタンスが分割できるような場合は、インスタンス分割でも良い）
非正規化の検討 †
DB運用関係（SQL Server） †
- インデックスのデフラグ・再構築（断片化の解消）
- 統計情報の再構築（クエリプランの再生成）
- データのアーカイブ（検索対象データ量を減らすなど）
Webサーバ構成 †
SSL（HTTPS）・HTTP圧縮（ → 必要であればアプライアンス化） †
静的コンテンツのキャッシュ（ → 必要であればキャッシュ サーバの導入） †
アプリケーションの実装 †
通信処理の周辺では性能劣化が多いので事前によく検証すると良い。 †
そもそも遅いテクノロジに注意 †
- COMの初期化
- プロセス間、マシン間通信（マーシャリング）など、ブラックボックス
のプロトコルは特に注意が必要（LANアナライザなどでシーケンスをチェックすると良い）。
クライアント － サーバ間のラウンド トリップ †
冗長なラウンド トリップは、ファサード パターンにより集約する。
- 3層C/S方式では通信ラウンドトリップや、データの整合性を考慮して、ファサード パターンにより１回のイベント処理に対して、１回のコネクション ＆ トランザクション（ ＝ １回のB層呼び出し）とする。
- 画面単位でマスタデータ・制御データをロード（ファサード パターン）し、保持するとラウンドトリップを軽減できる（また画面を開き直せば最新のマスタデータ・制御データをロードできる）。
DBアクセスのラウンド トリップの集約方法。 †
- 参照時のラウンド トリップを抑止
- 複数レコードの結果セットとして取得
- JOINを利用し、結合された結果セットとして取得
- O / Rマップしすぎると性能劣化する。
- 一覧ページのページング処理を工夫する（方式設計書テンプレートを参照）。
ページング †
メモリを大量消費して仮想記憶を使い出すと、
サーバ機としては致命的な性能劣化（32bitマシンは要注意）
- SELECT処理で結果セットを（必要以上に）大量に取得してしまう。
- フェッチ サイズを指定する。
- 初めは主キーのみを取得し、以降ページングする。
- DBのROWNUM機能を活用しページングする（方式設計書テンプレートを参照）。
インデックス スキャン †
- DBの検索処理の性能劣化は型不一致のインデックス スキャン発生などが劣化原因として多い。
- インデックス スキャンの発生は、DBのトレースを取得するなどして確認する。
UIの性能劣化 †
Web †
- Sessionの消去し忘れによるメモリ リーク
- 大容量画面のDOMアクセス性能劣化、ネットワーク トラフィック増加。
- JavaScript多用、inputmanなどJavaScriptを多用するコントロールによるロード処理遅延
- ViewState?の状態保持データ（実体はHidden）によるネットワーク トラフィック増加
RichClient? †
- 巨大画面のコントロールのロード処理遅延（UIコントロールのキャッシュ）
- RDPなどを使用した場合の画面再描画による画面データ転送遅延
- メモリ リーク
- 循環参照やフォームやコントロールのリーク（画面のCloseイベントなどを検知してメンバ変数などに保持している画面参照を破棄するなど）
- オブジェクトを不必要に溜め込み過ぎないようにする（UIコントロールのキャッシュ）。
- 画面描画
チラつきが気になる場合は、ダブル・バッファリングやSuspendLayout?の対策を施す。
- @IT > Insider.NET > .NET TIPS
テスト †
単体テスト（プロト、モック評価を含む） †
プロト、モックとプロファイラを使用して、
現行方式中のボトルネックなどを確認しておくと良い。
結合テスト †
処理時間を出力するログなどを埋め込んでおき、
処理時間の遅いものの原因を調査し、必要に応じて早期対応しておく。
負荷テスト †
- 本番環境に近い構成で組む。ピーク時の見積もり、評価を行う。
- オンラインの負荷テストの場合、負荷テスト ツールのスクリプトを組み合わせ、
本番で起き得るシナリオ（トランザクション パターン）をシミュレートする。
- サーバ リソース消費量はパフォーマンス カウンタ監視を用い、問題がないか確認する。
- APサーバが２層以上の複雑な構成であるなら、各サーバでの滞留状況も確認する。
- Microsoft系は自動チューニングが主流なので、パラメタ変更は
負荷テストの結果（パフォーマンス カウンタ監視）から判断する。
運用関係の性能チェック（設計＆検証） †
バッチ処理が時間内に終わるか。 †
バックアップか時間内に終わるか。 †
上記DB運用系操作が時間内に終わるか。 †
- インデックスのデフラグ・再構築
- データのアーカイブ、
障害復旧の時間確認 †
操作訓練 †
操作訓練も必要になる。
バックアップ・リストアの時間 †
フェールオーバ・フェールバックの時間 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
