Open棟梁 wiki

目次

概要

サーバ マシン

サーバ負荷分散(垂直分散)

リソース

CPU(コア)数

物理メモリ搭載量

ディスク性能

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

NIC性能

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

ネットワーク機器

ネットワーク負荷分散(水平分散)

ネットワーク帯域幅

ネットワーク品質

ミドルウェア全般

キャッシュ サイズ

CPUアフィニティ

NUMA

DB物理設計(SQL Server)

インデックス設計(インデックス特性を理解し使用すること)

クラスタ化インデックス

非クラスタ化インデックス

カバリング インデックス

付加列インデックス

インデックス ビュー

データ圧縮

ファイル分割

パーティション分割

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

非正規化の検討

DB運用関係(SQL Server)

・ 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サーバが2層以上の複雑な構成であるなら、各サーバでの滞留状況も確認する。  Microsoft系は自動チューニングが主流なので、パラメタ変更は 負荷テストの結果(パフォーマンス カウンタ監視)から判断する。

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

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

<Wink2>

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