Jmeter 学习笔记（二）

上一篇 / 下一篇 2011-08-05 19:01:33 / 个人分类：性能测试
汗，大概字数有上限吧，居然吞了我一半的内容，幸好ctrl c过，这边就做二吧
 
5、XML Assertion（XML断言）
 
就目前的理解来看XML Assertion的作用是判断返回结果是否否和xml的格式即<></>成对出现。（不知这样理解对不对？如果是这样的话，这个在HTML中，设置Format为XML就可以实现了，为什么还需要这个呢?）XML Assertion控制面板截图如下：
 
 
从控制面板上可以看出，XML Assertion不需要设置任何内容。
在使用XML Assertion的过程中，遇到一个问题，弄不明白，问题贴在这里，希望路过的朋友，如果知道的话，帮忙解答一下：
Jmeter中添加xml assertion
断言结果：Error on line 1: The element type "Detail" must be terminated by the matching end-tag "</Detail>".
但实际请求返回结果：
<?xml version="1.0" encoding="UTF-8"?><Info><Country>中国</Country><Province>未知</Province><City>未知</City><Type>大学</Type><ISP>教育网</ISP><Detail>中国教育网</Detail></Info>
问题：<Detail></Detail>是成对的，断言那边怎么会过不去？

comment：这篇是我看过比较全的对断言的解释了，就连官网上也没找到很详细的对每个断言的说明。。。不知道为啥还是我没找对地方

分布式测试：
作为一个纯 JAVA 的GUI应用，JMeter 对于CPU和内存的消耗还是很惊人的，所以当需要模拟数以千计的并发用户时，使用单台机器模拟所有的并发用户就有些力不从心，甚至还会引起JAVA内存溢出的错误。不过，JMeter 也可以像 LoadRunner 一样通过使用多台机器运行所谓的 Agent 来分担 Load Generator 自身的压力，并借此来获取更大的并发用户数。根据 JMeter官方文档的署名，你需要自己完成这个配置，不过不用担心，这将非常简单 ^_^
1.              在所有期望运行 JMeter 作为 Load Generator 的机器上安装 JMeter，并确定其中一台机器作为 Controller，其他的机器作为Agent。然后运行所有 Agent 机器上的JMeter-server.bat文件——假定我们使用两台机器 192.168.0.1 和 192.168.0.2 作为Agent；
2.              在Controller 机器的 JMeter 安装目录下找到 bin 目录，再找到 JMeter.properties 这个文件，使用记事本或者其他文字编辑工具打开它；
3.              在打开的文件中查找“remote_hosts=”这个字符串，你可以找到这样一行“remote_hosts=127.0.0.1”。其中的 127.0..0.1表示运行 JMeter Agent 的机器，这里需要修改为“remote_hosts=192.168.0.1:1664,192.168.0.2:1664”——其中的 1664为 JMeter 的 Controller 和 Agent 之间进行通讯的默认 RMI 端口号；
4.              保存文件，并重新启动 Controller 机器上的 JMeter.bat，并进入 Run -> Remote Start 菜单项。看到啥了？^_^

comment：我自己试过了，基本上和这里说的差不多，不过端口用的是默认的1099不是他写的1664，另外官网上说用作分布式测试的机器出了jmeter版本要一致外，就连java的版本最好也一致。
另外，下面是我自己试验分布式测试后的一些细节的记录：
1. agent的jmeter不需要运行case，只要启动了jmeter和jmeter- server.bat就可以了
2. case是在controller上运行的，report也体现在controller上
3. 根据资料，比方controller是设置了2次，共2个agent，那么一共是2*2=4次 （http://www.cnblogs.com/jackei/archive/2006/09/14/504638.html）
4. 看起来control如果要执行的话需要另外启动，不知道该如何一起启动（直接在properties中设置127.0.0.1是不行的）

结果分析（监听器）：
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 （这篇说的很细致，挺好的，记录这边）
Jmeter 学习笔记（二）

相关阅读:

用户菜单

我的栏目

标题搜索

日历

我的存档

数据统计

RSS订阅
