[[Open棟梁>https://github.com/OpenTouryoProject]] wiki

*目次 [#b14b802d]
#contents

*概要 [#v5dcbe9a]

*サーバ マシン [#pdf3275a]
**サーバ負荷分散（垂直分散） [#ndcf81d5]

**リソース [#ob07a4fc]
***CPU（コア）数 [#p63c8041]
***物理メモリ搭載量 [#p3fc00f7]
-アプリケーションの仮想アドレス空間（32bit、64bit、/3Gスイッチなどで変わる）
--32bit マシンの場合、/3Gスイッチや、AWE相当の機能を利用するなどを検討する。
--AWE：http://msdn.microsoft.com/ja-jp/library/ms175581.aspx

***ディスク性能 [#gd510e21]
ディスク、ディスク コントローラ性能と、RAID構成など。

***NIC性能 [#f06e1f5f]
NICの帯域幅、NICチーミングによる帯域幅増、負荷分散。

*ネットワーク機器 [#a6ded1a5]
**ネットワーク負荷分散（水平分散） [#m3fbda6a]
**ネットワーク帯域幅 [#c2e6a81d]
**ネットワーク品質 [#k3d681f9]
-べスト エフォート型サービスではサービスの品質(QoS)の保証がない。
-最低減の帯域幅、パケットロス率などに注意する。
-PacketShaper等のアプライアンスにより、品質改善することも可能。

*ミドルウェア全般 [#nbb37ffa]
**キャッシュ サイズ [#w3dad3be]
-キャッシュ サイズ（メモリ割り当てサイズ）
-他サーバと同居する場合はメモリ割り当てサイズを指定する。

**CPUアフィニティ [#vf543a12]
-他サーバと同居する場合はCPUアフィニティ マスクを指定する。

***NUMA [#n666546c]
-NUMAハードウェアで実行する場合、NUMA対応されているか？~
Non-Uniform Memory Access：http://msdn.microsoft.com/ja-jp/library/ms178144.aspx

 
*DB物理設計（SQL Server） [#fde50d14]
**インデックス設計（インデックス特性を理解し使用すること） [#g7c41cf4]
***クラスタ化インデックス [#za81de52]
***非クラスタ化インデックス [#oe6260ca]
***カバリング インデックス [#waa9b5b2]
***付加列インデックス [#mcae4172]
***インデックス ビュー [#b065cbf8]

**データ圧縮 [#a58a78e2]
-CPUリソースを犠牲にIOリソースを削減する。
-IOボトルネックを解消、一般的に性能は良くなる。

**ファイル分割 [#t131c289]
-ファイル グループ を使用した簡易RAID（ストライピング相当）
-また、部分的なバックアップ・リストア、段階的なリストアなど、運用系の時間短縮も可能。

**パーティション分割 [#z2227e49]
主に運用系性能（インデックスのデフラグ・再構築、データのアーカイブ）向上が可能だが、~
一部データ アクセス性能（並列クエリ、スキャン局所化、テーブル結合、ロック局所化）も改善。~
（インスタンスが分割できるような場合は、インスタンス分割でも良い）

**非正規化の検討 [#b063dfe9]

*DB運用関係（SQL Server） [#uffba737]
-インデックスのデフラグ・再構築（断片化の解消）
-統計情報の再構築（クエリプランの再生成）
-データのアーカイブ（検索対象データ量を減らすなど）

・	Webサーバ構成
	SSL（HTTPS）・HTTP圧縮（ → 必要であればアプライアンス化）
	静的コンテンツのキャッシュ（ → 必要であればキャッシュ サーバの導入）

 
・	アプリケーションの実装
	通信処理の周辺では性能劣化が多いので事前によく検証すると良い。
	そもそも遅いテクノロジに注意
COMの初期化、プロセス間、マシン間通信（マーシャリング）など、ブラックボックス
のプロトコルは特に注意が必要（LANアナライザなどでシーケンスをチェックすると良い）。

	クライアント － サーバ間のラウンド トリップ
冗長なラウンド トリップは、ファサード パターンにより集約する。

	DBアクセスのラウンド トリップの集約方法。
	参照時のラウンド トリップを抑止
	複数レコードの結果セットとして取得
	JOINを利用し、結合された結果セットとして取得

	更新時のラウンド・トリップを抑止
	配列バインドを使用
	ストアド プロシージャを使用

	O / Rマップしすぎると性能劣化する。
	一覧ページのページング処理を工夫する（方式設計書テンプレートを参照）。

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

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

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

	UIの性能劣化
	Web
	Sessionの消去し忘れによるメモリ リーク
	大容量画面のDOMアクセス性能劣化、ネットワーク トラフィック増加。
	JavaScript多用、inputmanなどJavaScriptを多用するコントロールによるロード処理遅延
	ViewStateの状態保持データ（実体はHidden）によるネットワーク トラフィック増加

	RichClient
	循環参照やフォームやコントロールのリーク
	巨大画面のコントロールのロード処理遅延
	RDPなどを使用した場合の画面再描画による画面データ転送遅延
 
・	単体テスト（プロト、モック評価を含む）
	Dev Partnerなどを使用して、
現行方式中のボトルネックなどを確認しておくと良い。


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


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


・	運用関係の性能チェック（設計＆検証）
	バッチ処理が時間内に終わるか。
	バックアップか時間内に終わるか。
	上記DB運用系操作が時間内に終わるか。
（インデックスのデフラグ・再構築、データのアーカイブ、
オフラインの場合は、バックアップ・リストアも含める）
	フェールオーバ・フェールバックの時間を確認
	障害復旧の時間確認（リストアなど操作訓練も必要になる）。

 
＜参考情報＞
＜Ｓｏｆｉ＞
性能実測時の目標値設定が明解！ATMゲートウェイシステムの性能設計書事例
http://sofi.itg.hitachi.co.jp/cgi-bin/sft/view/cnt-view.pl?solid=0000000000002393&refer=W2SCO

＜Ｗｉｎｋ２＞

1-6_品質関連情報

1-6-01_QNS ( 360 )
http://wink2.itg.hitachi.co.jp/kc/etime_/qa_/qns_/index.html

1-6-02_SBN（システム事故事例） ( 1316 )
http://wink2.itg.hitachi.co.jp/kc/etime_/qa_/sbn_/index.html

SBN02040：性能評価を実施する場合は、実運用相当の実施条件をすべて満たしているか
を考慮した結果判断しないと、システム性能の問題を見落とすことになる 2003/03/26
http://wink2.itg.hitachi.co.jp/kc/etime_/qa_/sbn_/time023151_/

以下ページを「性能」で検索して、ナレッジ情報を確認すると良い。

1-6-08_QFマニュアル ( 28 ) 

time025513：システム性能設計書作成手引書と参考事例 2004/08/11
http://wink2.itg.hitachi.co.jp/kc/etime_/qa_/qfm_/time025513_/index.html
time024985：システム性能設計ガイドライン 2004/04/01
http://wink2.itg.hitachi.co.jp/kc/etime_/qa_/qfm_/time024985_/index.html
time024984：システム信頼性設計、性能設計、稼働分析のチェックポイント 2004/04/01
http://wink2.itg.hitachi.co.jp/kc/etime_/qa_/qfm_/time024984_/index.html
time024982：C/S性能設計ガイドライン 2004/04/01
http://wink2.itg.hitachi.co.jp/kc/etime_/qa_/qfm_/time024982_/index.html
time024974：巨大データ処理システム性能設計/高信頼性設計リファレンス 2004/04/01
http://wink2.itg.hitachi.co.jp/kc/etime_/qa_/qfm_/time024974_/index.html
time024973：インターネット関連システム高信頼性/性能設計/稼働分析リファレンス 2005/12/12
http://wink2.itg.hitachi.co.jp/kc/etime_/qa_/qfm_/time024973_/index.html
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS