普通应用服务器监控工具

无需加好友免费技术支持

1. 数据建模工具

DataFactory允许开发人员和强大的数据生成器QA很容易产生百万行有意义的正确的测试数据库,该工具支持DB2、Oracle、 Sybase、SQL Server支持数据库ODBC不能直接使用连接方式MySQL可间接支持的数据库。

2. 脚本开发工具

（1） 如果考虑脚本的运行效率，可以考虑开发语言C或支持异步通信的语言JS,可分别选择：Loadrunner 或 Node.js的IDE开发环境。

（2） 如果考虑脚本开发效率，可以考虑代码重用性，可以选择面向对象的语言C#或Java，因此，我们可以分别选择：VS2008及以上版本 对应LR.NET控件 或者 Eclipse4.0及以上版本 JDK1.7及以上版本。

3. 压力模拟工具

（1） 若为Java如果类接口和单机并发数控制在500以内，可以选择Jmeter或者 Loadrunner。

（2） 若为WebService如果类接口和单机并发数控制在500以内，可以选择SoapUI或者Loadrunner。

（3） 若单机并发数超过500且控制在5000以内，则可选择Loadrunner。

（4） 如果单机并发数超过5000，建议采用负载集群，即中央控制（Control Center） 多机部署（LoadGenerator）”方案。

4. 性能监控工具

4.1 监控工具

无论Windows或Linux

平台通常有一组或一组进程实例，我们可以选择Loadrunner 或 Nmon 监控。有时，为了获得被测应用程序的一些特性指标，可以选择被测组件自带的性能工具集或监控系统。推荐普通应用服务器监控工具如下：

4.2 监控平台

监控机主要监控被测集群服务器的服务或资源使用，如各种开源监控工具，MRTG：流量监控；CACTI：流量预警，性能报告Smokeping:IDC 综合监控：Nagios、Zenoss、Ganglia 、Zabbix、Sitescope、Hyperic HQ 等，如下所示：

4.3 第三方监控云服务（APM）

APM提供移动、浏览器、应用、基础设施、网络、数据库性能管理等端到端应用性能管理软件和应用性能监控软件解决方案Java、.NET、PHP

、Ruby、Python

、Node.js、iOS

、Android

、HTML5

主流云服务包括听云、OneAPM等，如下所示：

性能测试结果分析

1. 指标分析

a.成功率b.失败率c.响应时间

a.容量：系统能承载的最大用户访问量是多少？系统最大的业务处理量是多少？

b.稳定性：系统是否支持7*业务访问24小时(一周)。

以上说明，测试人员在选择指标时需要从用户的角度进行思考。此外，为了更好地分析问题，他们还需要掌握与测试组件特性或操作原理相关的性能指标。

例如，接口系统通常直接或间接访问数据库层介质(如Mysql、Oracle、SQLServer等）此时，我们需要考虑接口系统在压力下存储介质的性能，通常我们会选择以下分析指标：

（1） 连接数（Connections） （2） 每秒查询数/每秒事务数（QPS/TPS） （3） 每秒磁盘IO数（IOPS） （4） 缓存命中率（Buffer Hits） （5） 每秒死锁数（Dead Locks/sec） （6） 每秒读写节数（Read/Write Bytes/sec） 2. 建模分析

2.1 理发店模型

图为标准软件性能模型。图中有三条曲线，分别表示资源的利用（Utilization，包括硬件资源和软件资源，吞吐量（Throughput，这是指每秒事务数和响应时间（Response Time）。图中坐标轴的横轴从左到右并发用户数（Number of Concurrent Users）不断增长。

在这张图中我们可以看到，最开始，随着并发用户数的增长，资源占用率和吞吐量会相应的增长，但是响应时间的变化不大；不过当并发用户数增长到一定程度后，资源占用达到饱和，吞吐量增长明显放缓甚至停止增长，而响应时间却进一步延长。如果并发用户数量继续增加，你会发现软硬件资源的占用继续饱和，但吞吐量开始下降，响应时间明显超出用户可接受的范围，最终导致用户放弃请求甚至离开。

根据这种性能，图中分为三个区域，即Light Load(轻压)，Heavy Load(重压)和Buckle Zone(用户无法忍受并放弃请求)。在Light Load和Heavy Load 我们称两个区域交界处的并发用户数为最佳并发用户数（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone两个区域交界处的并发用户数则称为“最大并发用户数（The Maximum Number of Concurrent Users）”。

当系统负载等于最佳并发用户数时，系统整体效率最高，无资源浪费，用户不需要等待；当系统负载在最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但用户等待时间延长，满意度开始下降，如果负载继续，最终会导致一些用户无法忍受和放弃；当系统负载大于最大并发用户数时，放弃注定会导致一些用户无法忍受超长的响应时间。因此，我们应该确保最佳并发用户的数量大于系统的平均负载。

2.2 压力变化模型

随着单位时间流量的不断增加，被测系统的压力越来越大，服务器资源将不断消耗，TPS 这些因素会改变值，并且符合一定的规律。

图中：

a 点：性能期望值 b 点：高于预期，系统资源处于临界点 c 点:高于预期，拐点 d 点:超载，系统崩溃

2.3 容量计算模型

以网站性能测试为例：

1. 通过分析操作数据，可以知道当前系统每小时处理PV数 2. 通过负载测试，我们可以知道系统每小时处理最多PV数

即整理得

系统每小时PV处理剩余量 = 系统每小时最大处理的PV数 — 每小时处理系统PV数

假设网站用户负荷基本呈线性增长，现有系统用户数量为70万，根据运营推广计划，网站开发用户将在一年内达到1000万，即增长14倍。

系统每小时PV处理增加量 = 当前系统每小时处理一次PV数 * 14 — 当前系统每小时处理一次PV数

系统负载每日增加率 = 100% / 365 = 2.74 % (注:这里将未来系统用户数达到1000万的负载定义为 100% ）

系统每天PV处理增加量 = 系统每小时PV处理增加量 * 系统负载每日增加率 * 24

因此，在正常负载条件下，我们可以知道：

该系统可支持正常运行天数 = 系统每小时PV处理剩余量 * 24 / 系统每天PV处理增加量

假设网站后续部署升级的天数已知，我们可以知道提前升级的天数：

该系统可支持正常运行天数 — 部署升级天数。

通过标准的性能测试

1. 所有计划的测试都完成了。

2. 已获得计划收集的所有性能数据。

3. 改进所有性能瓶颈，满足设计要求。