![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
[[Open棟梁Project>http://opentouryo.osscons.jp/]] - [[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]] -[[戻る>FrontPage#f588f56b]] *目次 [#o0e85b4e] #contents *概要 [#s471de5c] 性能設計のポイントをまとめる。 *サーバ マシン [#h064dd54] **サーバ負荷分散（垂直分散） [#s375c435] 垂直分散 -２層 ---> ３層化 -帳票出力処理 -非同期処理 -DBサーバ **リソース [#j282b08c] ***CPU（コア）数 [#w0ae3130] ***物理メモリ搭載量 [#v845c25c] -アプリケーションの仮想アドレス空間（32bit、64bit、/3Gスイッチなどで変わる） --32bit マシンの場合、/3Gスイッチや、AWE相当の機能を利用するなどを検討する。 --AWE：http://msdn.microsoft.com/ja-jp/library/ms175581.aspx ***ディスク性能 [#la6743e4] ディスク、ディスク コントローラ性能と、[[RAID]]構成など。 ***NIC性能 [#te8a453c] NICの帯域幅、NICチーミングによる帯域幅増、負荷分散。 *ネットワーク機器 [#wc06c89a] **ネットワーク負荷分散（水平分散） [#z5674674] ***Webサーバ [#y5582715] [[NLB]]負荷分散 -ロードバランサ - パーシステンスの種類~ http://www.infraexpert.com/study/loadbalancer5.html ***DBサーバ [#o54b8be7] [[シャーディング（水平的パーティション分割）>Elastic Scale, Elastic Database Pool]] -データベースのシャーディングを自動運用してくれる~ 「Azure SQL Database Elastic Scale」が公開 － Publickey~ http://www.publickey1.jp/blog/14/azure_sql_database_elastic_scale.html **ネットワーク帯域幅 [#l77a7f8b] **ネットワーク品質 [#ka9f9e05] -べスト エフォート型サービスではサービスの品質(QoS)の保証がない。 -最低減の帯域幅、パケットロス率などに注意する。 -PacketShaper等のアプライアンスにより、品質改善することも可能。 *ミドルウェア全般 [#f695e27e] **キャッシュ サイズ [#r8555188] -キャッシュ サイズ（メモリ割り当てサイズ） -他サーバと同居する場合はメモリ割り当てサイズを指定する。 **CPUアフィニティ [#r1155ad6] -他サーバと同居する場合はCPUアフィニティ マスクを指定する。 ***NUMA [#xe80f2ab] NUMAハードウェアで実行する場合、NUMA対応されているか？ -Non-Uniform Memory Access：~ http://msdn.microsoft.com/ja-jp/library/ms178144.aspx *DB物理設計（[[SQL Server]]） [#pb6b9728] **[[インデックス設計>SQL Server のインデックス]] [#t6efd003] [[インデックス特性を理解し使用すること。>SQL Server のインデックス]] **データ圧縮 [#p2103938] データを圧縮することにより、 -CPUリソースを犠牲にIOリソースを削減する。 -IOボトルネックを解消、一般的に性能は良くなる。 **[[ファイル分割>SQL Server のファイル・グループ]] [#o0b0e5e0] **[[パーティション分割>SQL Server パーティション分割]] [#q03eb1cd] **[[DBサーバの水平分散>#lac9d4fe]] [#pa081948] **非正規化の検討 [#s0bda421] *[[DB運用関係>SQL Server の管理]]（[[SQL Server]]） [#v299a727] *Webサーバ構成 [#af01618f] **SSL（HTTPS）・HTTP圧縮（ → 必要であればアプライアンス化） [#o71e50ae] **静的コンテンツのキャッシュ（ → 必要であればキャッシュ サーバの導入） [#i0326ba8] *アプリケーションの実装 [#hb75f5d1] **通信処理の周辺では性能劣化が多いので事前によく検証すると良い。 [#lf8fefd9] ***そもそも遅いテクノロジに注意 [#h1389411] -COMの初期化 -プロセス間、マシン間通信（マーシャリング）など、ブラックボックス のプロトコルは特に注意が必要（LANアナライザなどでシーケンスをチェックすると良い）。 ***クライアント － サーバ間のラウンド トリップ [#xc527a91] 冗長なラウンド トリップは、ファサード パターンにより集約する。 -3層C/S方式では通信ラウンドトリップや、データの整合性を考慮して、ファサード パターンにより１回のイベント処理に対して、１回のコネクション ＆ トランザクション（ ＝ １回のB層呼び出し）とする。 -画面単位でマスタデータ・制御データをロード（ファサード パターン）し、保持するとラウンドトリップを軽減できる（また画面を開き直せば最新のマスタデータ・制御データをロードできる）。 ***DBアクセスのラウンド トリップの集約方法。 [#s0d6eee2] -参照時のラウンド トリップを抑止 --複数レコードの結果セットとして取得 --JOINを利用し、結合された結果セットとして取得 -更新時のラウンド・トリップを抑止 --配列バインドを使用 --ストアド プロシージャを使用 -O / Rマップしすぎると性能劣化する。 -一覧ページのページング処理を工夫する（方式設計書テンプレートを参照）。 **ディスクI/Oボトルネック [#kbd0f97c] ***ページング [#cdae420e] メモリを大量消費して仮想記憶を使い出すと、~ サーバ機としては致命的な性能劣化（32bitマシンは要注意） -SELECT処理で結果セットを（必要以上に）大量に取得してしまう。 -フェッチ サイズを指定する。 -初めは主キーのみを取得し、以降ページングする。 -DBのROWNUM機能を活用しページングする（方式設計書テンプレートを参照）。 ***インデックス スキャン [#j9d1b973] -DBの検索処理の性能劣化は型不一致のインデックス スキャン発生などが劣化原因として多い。 -インデックス スキャンの発生は、DBのトレースを取得するなどして確認する。 **UIの性能劣化 [#de874b26] ***Web [#q041d7f6] -Sessionの消去し忘れによるメモリ リーク -大容量画面のDOMアクセス性能劣化、ネットワーク トラフィック増加。 -JavaScript多用、inputmanなどJavaScriptを多用するコントロールによるロード処理遅延 -ViewStateの状態保持データ（実体はHidden）によるネットワーク トラフィック増加 ***RichClient [#c7b36b6c] -巨大画面のコントロールのロード処理遅延（UIコントロールのキャッシュ） -RDPなどを使用した場合の画面再描画による画面データ転送遅延 -メモリ リーク --循環参照やフォームやコントロールのリーク（画面のCloseイベントなどを検知してメンバ変数などに保持している画面参照を破棄するなど） --オブジェクトを不必要に溜め込み過ぎないようにする（UIコントロールのキャッシュ）。 -画面描画~ チラつきが気になる場合は、ダブル・バッファリングやSuspendLayoutの対策を施す。 --@IT > Insider.NET > .NET TIPS ---ダブル・バッファリングにより描画を行うには？~ http://www.atmarkit.co.jp/fdotnet/dotnettips/197doublebuf/doublebuf.html~ http://www.atmarkit.co.jp/fdotnet/dotnettips/449doublebufed/doublebufed.htm ---ウィンドウのリサイズ時に再描画を行うには？~ http://www.atmarkit.co.jp/fdotnet/dotnettips/191resizedraw/resizedraw.html ---背景の描画を禁止して再描画時のちらつきをなくすには？~ http://www.atmarkit.co.jp/fdotnet/dotnettips/194nopaintbg/nopaintbg.html --DOBON.NET >コントロールを実行時に作成する~ http://dobon.net/vb/dotnet/control/addcontrol.html *テスト [#wd81761d] **単体テスト（プロト、モック評価を含む） [#nedcbad6] プロト、モックとプロファイラを使用して、~ 現行方式中のボトルネックなどを確認しておくと良い。 **結合テスト [#jcf31735] 処理時間を出力するログなどを埋め込んでおき、~ 処理時間の遅いものの原因を調査し、必要に応じて早期対応しておく。 **負荷テスト [#ud0a5651] -本番環境に近い構成で組む。ピーク時の見積もり、評価を行う。 -オンラインの負荷テストの場合、負荷テスト ツールのスクリプトを組み合わせ、~ 本番で起き得るシナリオ（トランザクション パターン）をシミュレートする。 -サーバ リソース消費量はパフォーマンス カウンタ監視を用い、問題がないか確認する。 -APサーバが２層以上の複雑な構成であるなら、各サーバでの滞留状況も確認する。 -Microsoft系は自動チューニングが主流なので、パラメタ変更は~ 負荷テストの結果（パフォーマンス カウンタ監視）から判断する。 *運用関係の性能チェック（設計＆検証） [#a5bb2afb] **バッチ処理が時間内に終わるか。 [#ted87692] **バックアップか時間内に終わるか。 [#f2caafb7] **上記DB運用系操作が時間内に終わるか。 [#g89913e3] -インデックスのデフラグ・再構築 -データのアーカイブ、 **障害復旧の時間確認 [#d35ebc6d] ***操作訓練 [#i21b294f] 操作訓練も必要になる。 ***バックアップ・リストアの時間 [#q75abc35] ***フェールオーバ・フェールバックの時間 [#j9e4227c]
