jmeter结果分析（监听器）：

结果分析（监听器）：

1.聚合报告

Aggregate Report 是 JMeter 常用的一个 Listener，中文被翻译为“聚合报告”。今天再次有同行问到这个报告中的各项数据表示什么意思，顺便在这里公布一下，以备大家查阅。

如果大家都是做Web应用的性能测试，例如只有一个登录的请求，那么在Aggregate Report中，会显示一行数据，共有10个字段，含义分别如下。

Label：每个 JMeter 的 element（例如 HTTP Request）都有一个 Name 属性，这里显示的就是 Name 属性的值

#Samples：表示你这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100

Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间

Median：中位数，也就是 50％ 用户的响应时间

90% Line：90％ 用户的响应时间

Note：关于 50％ 和 90％ 并发用户数的含义，请参考下文

http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html

Min：最小响应时间

Max：最大响应时间

Error%：本次测试中出现错误的请求的数量/请求的总数

Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数

KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec

2. 图形报表

图表底部参数的含义如下：
样本数目是总共发送到服务器的请求数。
最新样本是代表时间的数字,是服务器响应最后一个请求的时间。
吞吐量是服务器每分钟处理的请求数。 
平均值是总运行时间除以发送到服务器的请求数。 
中间值是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。 
偏离表示服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。

3. 监视器结果

“监视器结果”（Monitor Result）是为Tomcat 5设计的，用来实时反映服务器的性能情况，如果你的AppServer不是Tomcat 5，使用“监视器结果”得不到结果，但是任何servlet container都可以移植status servelet并使用此monitor，如果需要对其他的AppServer使用该Monitor，需要移植Tomcat 5的status servelet。

添加JMeter的“监视器结果”利用的是Tomcat本身的特性，就是直接访问Tomcat服务器的/manager/status，获得相应的服务器状态数据并进行呈现。因此，在JMeter中添加“监视器结果”来监视服务器状态的步骤如下：

1.                 增加一个HTTP Request的Sampler；

2.                 选中该新增的HTTP Request，修改其属性：

修改“名称”为服务器状态（非必须）

修改“路径”为manager/status，必要时给出服务器的IP地址和Port的值

增加一个参数，该参数的名称为大写的XML，值为小写的true

选中下方的“用作监视器”

如下图所示：

 

 

3.                 增加一个“http授权管理器”因为访问Tomcat的应用服务器的/manager/status需要给出用户名和口令。如下图所示

 

 

4.                 添加一个“监视器结果”的节点

执行后，会在监视器结果中的性能页面显示图。其中healthy/Warning/非活动”是根据服务器上的可用线程数/最大可用线程数得出，而Load用来衡量应用服务器的压力状况。

comment：我知道经常用的还有“察看结果树”以及“用表格察看结果”，这篇监视器结果我觉得网上不太多吧，大部分都说聚合报告

其他：

1. 聚合报告的error代表没有响应率

2. 每个测试不能一下子上1000，应该10 100 200 500 1000这样的走，看下错误的上升率

3. 每个case要跑3次，取平均值，以排除外界干扰

4. 例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能

5. 压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

6. 并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；

7. 同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等

8. 主要的测试指标包括交易处理性能指标和UNIX资源监控。其中，交易处理性能指标包括交易结果、每分钟交易数、交易响应时间（Min：最小服务器响应时间；Mean：平均服务器响应时间；Max：最大服务器响应时间；StdDev：事务处理服务器响应的偏差，值越大，偏差越大；Median：中值响应时间；90%：90%事务处理的服务器响应时间）、虚拟并发用户数。

9. 监测的测试指标包括交易处理性能以及UNIX（Linux）、Oracle、Apache资源等。

10. 是否需要疲劳性测试？

11. 基准测试可以在一个相对短的时间内收集可重复的结果。进行基准测试的最好方法是，每次测试改变一个且只改变一个参数。例如，如果想知道增加JVM内存是否会影响应用程序的性能，就逐次递增JVM内存（例如，从1024 MB增至1224 MB，然后是1524 MB，最后是2024 MB），在每个阶段收集结果和环境数据，记录信息，然后转到下一阶段。这样在分析测试结果时就有迹可循。下一小节我将介绍什么是基准测试，以及运行基准测试的最佳参数。

12. 　基准测试的关键是要获得一致的、可再现的结果。注意，吞吐量以稳定的速度增长，然后在某一个点上稳定下来。因为服务器上所有的线程都已投入使用，传入的请求不再被立即处理，而是放入队列中，当线程空闲时再处理。　当系统达到饱和点，服务器吞吐量保持稳定后，就达到了给定条件下的系统上限。　注意，在执行队列（图2）开始增长的同时，响应时间也开始以递增的速度增长。这是因为请求不能被及时处理。

13. 对于一次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。

14. 与此相对应的是“ramp-up”测试。

　　ramp-up测试中的用户是交错上升的（每几秒增加一些新用户）。ramp-up测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。因此，flat运行是获得基准测试数据的理想模式。

15. 这不是在贬低ramp-up测试的价值。实际上，ramp-up测试对找出以后要运行的flat测试的范围非常有用。ramp-up测试的优点是，可以看出随着系统负载的改变，测量值是如何改变的。然后可以据此选择以后要运行的flat测试的范围。

16. 　当测试中所有的用户都同时执行几乎相同的操作时，就会发生这种现象。这将会产生非常不可靠和不精确的结果，所以必须采取一些措施防止这种情况的出现。有两种方法可以从这种类型的结果中获得精确的测量值。如果测试可以运行相当长的时间（有时是几个小时，取决于用户的操作持续的时间），最后由于随机事件的本性使然，服务器的吞吐量会被“拉平”。或者，可以只选取波形中两个平息点之间的测量值。该方法的缺点是可以捕获数据的时间非常短。

17. 例如，首先使用ramp-up测试确定系统可以支持的用户范围。确定了范围之后，以该范围内不同的并发用户负载进行一系列的flat测试，更精确地确定系统的容量。

18. 可行的方法是在这台服务器上使用不同级别的负载来进行测试，并根据测试数据获得系统在这种环境下的最佳负载和最大负载，并根据测试数据对负载和资源消耗的情况进行估算，找到它们之间的关系。

19. 而对于可伸缩性测试，通常来说是要根据并发量、系统的性能表现以及软硬件资源的消耗情况来进行分析，并使用数学建模的方式获得一个容量模型。

20. 可伸缩性测试（Scalability Testing） 对于一个系统来说，在一个给定的环境下，它的最佳并发用户数和最大并发用户数是客观存在的，但是系统所面临的压力却有可能随上线时间的延长而增大。例如，一个在线购物站点，注册用户数量不断增多，访问站点查询商品信息和购买商品的人也不断的增多，我们应该用一种什么样的方案，在不影响系统继续为用户提供服务的前提下来实现系统的扩容？

21. Jmeter的并发数是没有上限的（http://bbs.51testing.com/thread-264979-1-3.html）

comment：上面其实主要是一些测试性能的指标，还有思路（不是光把jmeter跑起来就可以的，要知道怎么设定跑的次数以及check的点这些）

好啦，基本上记录的差不多了，当然文章还有好多好多，不过没办法都记录在博客中，这边就作为一个大致的流程记录下来吧，如果以后再有什么好发现，我可以开一个二，呵呵

btw, http://shijianwu1986-163-com.iteye.com/blog/507888 （这篇说的很细致，挺好的，记录这边）