まず、主要な指標を監視する必要があるどのようなソフトウェアのパフォーマンステスト？
主に以下の3点の汎用ソフトウェアのパフォーマンステスト：
Ø現在の性能評価システムは、システムが期待される性能要件を満たしているかどうかを決定します。
Øソフトウェアシステムは、存在してパフォーマンスのボトルネックを見つけ、問題を解決することがパフォーマンスの問題を見つけることができます。
Øは、システムのパフォーマンスを評価し、適用前の展開に、ソフトウェアシステム、予測可能なシステム負荷圧力の許容範囲の性能を決定します。
ユーザーの場合、現在のシステム最も懸念：
Øライン上の性能要件を満たすかどうか？
Øベアリングシステムの限界をどのように？
Øどのようにシステムの安定性？
したがって、上記の性能テストを目的と利用者の懸念のため、上記の目的を達成するために、ユーザーの懸念に答えるために、それは最初のパフォーマンステストおよび収集するための明確な必要性を行わなければならない、パフォーマンス・テスト・モニタリング指標メイン、通常の状況下では、監視するための重要な指標ものです分割：システム・メトリックおよびリソースインジケータ、示されるように、リソースインデックスは、直接ハードウェアリソースの消費に関連して、システムインデックスは、直接ユーザとシーンのニーズに関連しています。
テストは、主要な指標の説明を監視することができます。
Ø リソース指標
CPU使用率：システムプロセスと消費されたCPU時間のユーザー・プロセスの割合、時間は、一般的に受け入れられて上限は85％以下です。
使用メモリ：メモリ使用率=（1 -空きメモリ/総メモリサイズ）* 100％、利用可能なメモリの一般的には少なくとも10％、85％のメモリ使用量許容限界。
ディスクI / O： 保存されたデータは、書き込みIO操作に対応したときに対応するデータが取られたときディスクは主に、それはIO操作に来るときに、対応する二つの操作がありますが、データにアクセスするために使用されますIOは、読み出し動作を一般的にディスクの読み取りおよび書き込みのパフォーマンスを測定する（ディスクによって占められる割合は動作時間を読み書き）％のディスクの時間を用いています。
帯域幅：カウンタを使用して船は合計バイト/秒、測定された合計バイト/秒の速度は、フレーミング文字が含ま含む、バイトの送受信のように表現されます。ネットワーク接続速度がボトルネックであるかどうかを決定する、帯域幅は、カウンタ値と現在のネットワークと比較することができます。
Ø システム仕様：
同時ユーザー：物理的な時間のユーザーがシステムに要求を提出します。
オンラインユーザー：一定の期間内にシステムにアクセスするユーザー数、これらのユーザーは、必ずしもシステムへの要求を提出していません。
平均応答時間：トランザクション処理システムの平均応答時間。トランザクションの応答時間は、クライアントが、クライアントからサーバーの応答によって消費される時間を受け取りアクセスするための要求を提出することです。迅速なシステム応答クラス・ページの場合、応答時間は、典型的には約3秒です。
トランザクション成功率：パフォーマンステストは、そのようなユーザのログインなどのビジネスプロセスを、複数のトランザクションやパフォーマンスメトリックの定義、順序を保存し、以下のように、操作は、オーダー提出トランザクションのように定義することができます。
次のようにシステム定義のトランザクションの数が正常に完了することができる時間の単位、システムの反応処理能力ある程度、一般トランザクション成功率メトリックは、計算されます。
タイムアウトエラーレートは：主に総トランザクションの失敗率を引き起こした原因タイムアウトまたは他の内部システムエラーにトランザクションを指します。
第二に、どのように重要な指標を監視するには？
Ø リソース監視指標
各サーバプラットフォーム（WindowsやLinux、Unixの、など）のためのメインモニタリソースの使用状況。
こうしたWindowsシステムとして、システムの独自のパフォーマンス監視ツールのモニターやサードパーティのツールを使用することができ、以下に示すように、「システムのパフォーマンスモニタ」来ます。
以下に示すように、などのIOメモリ、CPU、ディスク使用量を監視するためのコマンドiostatのLinuxシステム、無料、vmstatの、SAR、：
以下に示すようなスポットライトなどのサードパーティ製の監視ツールは、スポットライトはクエストによって開発された可視化ツールは、プラットフォームやデータベースシステムのさまざまな監視することができますされています。
NMONは、IBMが提供するAIXおよびLinuxシステムのリソース無料ツールを監視している以下に示すように、直感的なExcelのグラフの形成の統計分析によって収集された情報リソースことができます。
入出力 システム監視指標
系统指标监控一般通过性能测试工具（如LoadRunner、Jmeter等）以图形化方式监控，如下图所示，并发用户数与平均响应时间关系图。
三、如何分析监控的关键指标？
通过第二部分监控收集到性能度量关键指标，如何进行分析，并判断是否存在性能瓶颈呢？以下主要从资源指标与系统指标两方面进行阐述。
Ø 资源指标分析
判断CPU是否是瓶颈的方法：一般情况下CPU满负荷工作，有时候并不能判定为CPU出现瓶颈，比如Linux 总是试图要CPU尽可能的繁忙，使得任务的吞吐量最大化，即CPU尽可能最大化使用。因此，一般判断CPU为瓶颈，主要从两方面：一是CPU空闲持续为 0，二是运行队列大于CPU核数（经验值3-4倍），即可判定存在瓶颈，对于CPU高消耗主要由什么引起的，可能是应用程序不合理造成，也可能是硬件资源 不足，需要具体问题具体分析，比如问题SQL语句引起，则需要跟踪并优化引起CPU使用过高的SQL语句。
判断内存是否是瓶颈的方法：一般至少有10%可用内存，内存使用率可接受上限为85%。当空闲内存变小时，系统开始频繁地调动磁盘页面文件，空闲内存过小可能是内存不足或内存泄漏引起，需要根据系统实际情况监控分析。
判断磁盘I/O是否是瓶颈的方法：磁盘I/O对于数据库服务器、文件服务器、流媒体服务器系统来说，更容易成为瓶颈，一般从以下几个方面对磁盘I/O进行分析判断：
① 计算每磁盘I/O数
每磁盘I/O数可用来与磁盘的I/O能力进行对比，如果经过计算得到的每磁盘I/O数超过了磁盘标称的I/O能力，则说明确实存在磁盘的性能瓶颈，每磁盘I/O计算方法如下表：
| RAID类型 |
计算方法 |
| RAID0 |
(Reads+Writes)/Numbers of Disks |
| RAID1 |
(Reads+2*Writes)/2 |
| RAID5 |
[Reads+(4*Writes)] /Numbers of Disks |
| RAID10 |
[Reads+(2*Writes)] /Numbers of Disks |
② 监控磁盘读写，如果磁盘长时间进行大数据量读写操作，且cpu等待超过20%，则说明磁盘I/O存在问题，考虑提高磁盘I/O读写性能。
判断网络带宽是否是瓶颈的方法：判断网络带宽是否是系统运行性能瓶颈的首要条件是网络带宽是否会影响系统交易执行性能。例如：减小网络带宽，并发用户数、响应时间与事务通过率等性能指标是否不能接受；或者增加网络带宽，并发用户数、响应时间与事务通过率等性能指标会得到明显提高。
在实际性能测试中，如果发现始终报连接超时，而实际手工访问可以正常访问，可以通过ping应用服务器IP或网关IP，如果出现网络严重延迟或丢包，则说明网络不稳定，需要检查网络。
通过对资源指标四个指标的分析，实际上各个方面都是互相依赖的，不能孤立的单从某个方面进行排查。当一个方面出现性能问题时，往往会引发其他方面的 性能问题，例如，大量的磁盘读写势必消耗CPU和IO资源，而内存的不足会导致频繁地进行内存页写入磁盘、磁盘写到内存的操作，造成磁盘IO瓶颈，同时， 大量的网络流量也会造成CPU过载，所以，在分析性能问题时，需要从各个方面进行考虑。
Ø 系统指标分析
并发用户数：系统能够支持的用户数是系统容量的重要标志，并发用户数用于度量系统在高并发量访问下，系统的并行处理能力，一般如果系统中存在死锁、资源争用，在并发访问下，由于请求处于队列等待中，系统响应就会随着时间变慢。
一般情况下，选用高吞吐量、高数据库I/O、高商业风险的业务功能进行并发用户访问测试。
判断系统能够承受的最大并发用户数，通常以满足以下条件为准：
1、业务功能操作平均响应时间在合理范围之内
2、事务成功率在合理范围之内
3、 系统运行无故障（无异常宕机）
4、系统资源指标使用在合理范围内
平均响应时间：对于客户端用户来说，最直观的体验就是访问该页面快或者慢，即响应时 间的长短。比如在持续并发性能测试过程中，客户感知访问应用很慢，监控到的平均响应时间也逐渐变长，这时就需要先借助于监控到的资源指标，首先排除资源方 面的限制因素，再从应用本身进行定位，如可以采用页面细分工具（如httpwatch、Loadrunner Anaysis中的页面组件细分）分析响应比较慢的页面。
事务成功率、超时出错率：事务成功率越高，则表明系统处理能力越大；而失败事务主要由于系统响应慢，导致访问业务功能超时，或者系统业务功能异常，不能正常访问等，需要根据事务错误提示信息，具体分析。