loadrunner整体使用篇

• 为何要进行性能测试呢？  有些问题是只有在大并发或者压力测试下才会暴露出来的，在日常的公司内部测试中，感受一切都是正常的，可是把服务放到生产线上，例如某个时刻忽然有不少的用户要向咱们的服务发送请求，这时候就考验到咱们的服务是否会死锁，内存泄漏，可否在一个可接受的范围内响应，会不会crash，可否处理全部的请求（或者容许损失必定量的请求，好比1%内）等。为了避免给用户糟糕的体验，因此咱们须要在服务上生产线以前就要作好性能测试，但要作好性能测试，除了编写正确的性能脚本外，也须要分析不少因素的（主要有3大块：负载机、网络、被测系统），因此我但愿本身能从日常中的点滴开始积累然经验后不断扩展。 在性能测试开始以前，是要保证你所要测试的场景中所涉及到的功能测试都已经能跑通，要否则到时候你会崩溃的QAQ
• 要作一个完整的性能测试要有哪些步骤？

–      1. 虚拟用户脚本编写（模拟用户实际操做）

–      2. 场景设计&运行（例如要5000个用户同时登陆到会议室）

–      3. 分析结果报告

• 如何选择性能测试工具？

–      1.  只选对的，不选贵的。个人意识是根据本身所测的服务器对外提供了什么协议类型的API来进行相应的选择，好比我所处的平台新服务器对外提供了HTTP协议的API和基于SessionManager的TCP协议的API。关于HTTP协议的压测工具却是有不少的，你们本身百度下，可是关于能测TCP协议的压测工具，我知道的而且会使用的并很少，只知道能够用能支持socket协议的压测工具来实现

–      2. 选的测试工具能按本身但愿的步骤来编写虚拟用户脚本（而不是根据测试工具提供的录制步骤来完成虚拟用户脚本）

–      3. 有良好的场景设计功能

–      4. 有易于查看的输出报告

–      5. 有中文文档以及google或者百度等上能搜索到较多的疑问解答

         综上所述，我选择了Loadruner做为我平台服务器初期的性能测试工具，并且loadrunner提供类C语言的脚本编写（咱们在大学都应该学过C/C++，有必定的基础能帮助咱们更快的熟悉脚本编写）。可是因为loadrunner不易于扩展，是商用工具，要想无偿使用只能用loadrunner11版本的破解版，loadrunner11是很早以前的版本，对于一些新功能是没法支持的（例如：咱们开发提供了一个SDK的DLL，在LR11中没法加载运行，但在LR12中能够加载运行）。总之工具只是帮助咱们完成任务的，要想更好的完成任务，咱们就须要不断的探索更多的解决办法（之后我会分享其余的开源性能测试工具或者如何本身编写一个适合咱们被测系统的压测代码）

 

• Loadrunner的使用     

–      下图显示的是LR的3个主要组件，其中Virtual User Generrator是用来编写虚拟用户脚本的

–      Controller是用来设计场景的

–      Analysis是用来分析运行数据，生成结果报告的

–      结合我实际工做中的项目来演示如何使用这3个组件的

 

Virtual User Generator

         因为咱们要本身来设计脚本执行的流程顺序，暂时使用不到loadrunner提供的录制功能，因此打开Virtual User Generator,点击New Script而后选择一个通用的协议，例如Web(HTTP/HTML)后点击Create按钮，通过这些步骤后，就为咱们提供了一个初步的编写脚本用的模版了

 

•       Virtual User Generator

 

–      虚拟用户脚本的设计是要考虑到典型场景的，例如一个会议室登陆多个用户、多个会议室登陆多个用户等等，接下来的demo将是针对一个会议室登陆多个用户的场景的。先上图再逐一分解

 

–      与最初建立的模版相比，发现上图左边的工程区里面多了cJSON.h和JsonDemo.dll2个文件，因为LR支持加载纯C编译的DLL，因此咱们就能够像使用python那样import XX包进来，而后直接使用其中的方法来帮助咱们编写脚本，关于cJSON.h和JsonDemo.dll2个文件这2个文件的做用，将在接下来的脚本分析中说明吧

 

先上2张我实际写的项目脚本，为下面的解析提供依据：

Login_CreateGroup脚本：

 

• Virtual User Generator

–      如何找到纯C的源程序，而后编译成dll，最后导入到loadrunner中为咱们所用？就拿刚刚的JsonDemo.dll来讲明吧

–      1. 登陆到Json的官网（www.json.org），找到C的源码而后下载

–      2. 打开Visual Stutio，New一个空的project，选择Visual C++下的Win32 Console Application，而后把Application Type选择为DLL

–      3. 右键点击Header Files，Add一个Existing Item…把刚刚下载的C的源码里面的cJSON.h添加进来，一样右键点击Source Files， Add一个Existing Item…把刚刚下载的C的源码里面的cJSON.cpp添加进来

–      4. Build Solution生成DLL（编译过程当中若是有安全提示的话，能够在command line中输入/D “_CRT_SECURE_NO_WARNINGS” 来解决）

 

platfrom_room脚本：

 

• Controller

–      虚拟用户脚本已经编写好了， 可是虚拟用户脚本只是表明一个用户的某种行为，要想实现并发操做，那就是要模拟不少用户（例如2000个用户）的相同操做。

–      在真正的实际设计场景前，有几个概念须要理解下，什么是“系统用户数”、“在线用户数”、“并发用户数”？举一个例子来讲明下， 假设有一个综合性的网站，用户只有在注册后登陆系统才可以享有新闻、论坛、博客、免费信箱等服务内容，经过数据库统计知道了系统的用户数量为4000人，4000即为“系统用户数”；经过操做日志能够知道，系统最高峰时有500个用户同时在线，这里“在线用户数”即为500；这500个用户的需求确定是确定是不尽相同的， 有的人喜欢看新闻、有的人喜欢写博客、收发邮件等。假设70%的人在看新闻，10%的人什么也不干，剩下的20%的人写博客（收发邮件或者不停的跳转页面），那么真正对服务器形成压力的就是这500人中的20%（100人）。那么如何估算“并发用户数”？

–      （1）C=nL/T      (2) C1=C+3 √3

–      在公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T是考察的时间段长度。

–      在公式（2）中，C1是并发用户数的峰值，C就是公式（1）中的获得的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算获得的

–      下面给出一个实例来说述公式的应用。假设有一个OA系统，该系统有3000个用户，平均天天有大约400个用户要访问系统，对一个典型用户来讲，一天以内用户从登陆到退出系统的平均时间为4h，在一天以内，用户只在8小时以内使用该系统。带入公式（1）获得C=400*4/8=200，那么C1=200+3* √200=242

–      除了上述方法外，还有一种更为普遍但精度比较差的根据经验的方法，相应的经验公式为：C=n/10和C1=r*C。一般用访问系统用户最大数量的10%做为平均的并发用户数量；并发用户数的最大数量能够经过在并发数上乘以一个调整因子r获得，一般r的取值为2~3。

–      固然在我实际测试过程当中的话，我是根据负责人要求的来进行并发测试，好比我主管说服务器要支持5000的并发请求，那么我就按照5000来设计了，等服务上线后，我会查看日志、数据库而后运用上面的公式再来分析每一个阶段实际的并发用户数。

 

• Controller

–      1. 打开Controller，会出现一个“New Scenario”对话框，把刚刚编写好的”Login_CreateGroup”和”platform_room”这2个脚本添加到“Scripts in Scenario”。为何要添加2个脚本，而不是在一个脚本中把咱们要操做的步骤所有编写好呢？ 这就有点像写代码，咱们会把一些常常要用的且能共用的弄成一个库，那样谁要用的时候就直接引入这个库，会提升效率。因此在设计我平台服务器的性能脚本时候，我就尽可能把每一个接口都各自编写成脚本，而后在场景设计中就把这些脚本进行组合。

–      2. 这里介绍下“Schedule by”中的2个重要选项“Scenario”和“Group”,Scenario(场景)：当你按场景进行计划时候，Controller将会同时运行全部参与场景的Vuser组，也就是说，定义的场景运行计划同时应用与全部Vuser组，而Controller将每一个操做按比例应用与全部Vuser；Group（组）：当你按Vuser组进行计划时，参与场景的每一个Vuser组按其本身单独的计划运行，也就是说，对于每一个Vuser组，你能够指定什么时候开始运行Vuser组，更直白一点的说，就是当Vuser组和Vuser组之间有依赖关系的时候，就用Group方式。

–      3. 接下来就说说我设计的场景，根据业务我须要先登陆验证（会返回token），建立分组（会返回groupid），而后请求分配服务地址和登陆会议室，因此呢，我只须要登陆和建立分组一次，就能拿到后续登陆会议室须要的token和grouip，因而我只要运行脚本“Login_CreateGroup”一次，而后再运行脚本“platform_room”不少次就能实现“一个会议室同时登陆不少人”的场景，并且这里须要注意的一点是，这2个脚本是有依赖关系的，“Login_CreateGroup”是要在“platform_room”前面先执行完后，“platform_room”才能执行的。对应到Controller里面的设置以下图：

 

 

 

 

 

• Controller

–      4. 场景设计完了， 接下来就能够执行了， 可是咱们性能测试不仅仅只是给被测系统加压， 咱们还要关注整个测试过程当中产生的数据， 而后选出咱们所关心的数据，为进一步分析定位问题提供帮助。因此呢， 在开始RUN以前，咱们先添加一下本身关心的，要监控的数据，下图是我监控的一些数据：

 

 

• Controller

–      5. 接下来就能够RUN了， 在Running过程当中可能会遇到一个问题就是loadrunner卡在那边不动了， 而后后面的case都失败了， 经过观察监控的“Windows Resources”发现某一时段内CPU达到100%了，究其缘由发现是由于设置太多的Vusers了（好比5000），这时候负载机由于自身的资源条件限制而引发的，为了解决这一问题，咱们能够采用loadrunner的分布式加压来解决。

–      什么是分布式加压呢？ 分布式加压其实就是用另一台负载机来帮助咱们实现必定量的Vusers，那么咱们就须要在另外一台负载机上安装loadrunner11软件，而后在本地负载机的Controller的Load Generators里Add另外一台负载机的Name（能够填写IP地址，好比192.168.6.173），而后点击connect按钮，查看status是否变为Ready状态，最后就能够在不一样的虚拟用户组指定不一样的负载机来帮助咱们完成性能测试了。

–      具体操做步骤能够参考网上的资料：http://blog.csdn.net/wuyepiaoxue789/article/details/51799657

         场景运行完成之后， 不表明咱们的性能测试结束， 相反，这才是性能测试的开始，由于接下来，咱们须要对运行数据进行分析，找出性能瓶颈，而后调优或者提交BUG。

 

• Analysis

–      在介绍Analysis的使用以前， 下面将针对一些经常使用的监控资源进行说明。

• 我大体将监控分为3类
• ①负载机的系统监控与被测系统监控（通常包括CPU使用率、内存、磁盘IO等）
• ②服务器处理能力的指标监控（通常包括吞吐量、每秒事物数、各个事物的响应时间、每秒单击数等）
• ③网络监控（根据经验，就是查看对比先后流量，ping服务器等）

–      CPU利用率（% Processor Time）：指处理器执行非闲置线程时间的百分比。这个计数器设计成用来做为处理器活动的主要指示器。它经过在每一个时间间隔中衡量处理器用于执行闲置处理线程的时间，而且用100%减去该值得出。可将其视为范例间隔用于作有用工做的百分比。根据应用系统状况，在80%±5%范围内波动为宜。太低，则服务器CPU利用率不高；太高，则CPU可能成为系统的处理瓶颈。

–      可用物理内存（ Available MBytes ）：当这个数值变小时，Windows开始频繁地调用磁盘页面文件。若是这个数值很小，例如小于5 MB，系统会将大部分时间消耗在操做页面文件上。通常要保留10%的可用内存。最低不能<4M，此值太小多是内存不足或内存泄漏。

–      磁盘IO（% Disk Time）：指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。正常值<10，此值过大表示耗费太多时间来访问磁盘，可考虑增长内存、更换更快的硬盘、优化读写数据的算法。若数值持续超过80 (此时处理器及网络链接并无饱和)，则多是内存泄漏。

–      事务平均响应时间:（ Average Transaciton Response Time ）：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，总体性能将会有降低的趋势。好<2s、良好2~5s、差6~10s

–      吞吐量（ Throughput ）:能够依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。

–      每秒点击次数（ Hits per Second ）:经过对查看“每秒点击次数”，能够判断系统是否稳定。系统点击率降低一般代表服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

虚拟用户数（Running Vusers）: 这个主要用于与其余监控数据结合来分析问题的。

 

• Analysis
• 执行结果分析过程

–      场景执行完成之后，须要对运行过程当中收集的数据信息进行分析，从而来了解系统性能表现能力，肯定系统性能瓶颈。在Loadrunner Controller中，经过单击【Results】>【Analyze Results】菜单项，启动Loadrunner Analysis应用，若是左侧的Graphs中没有出现你想要的图，就点击工具条按钮“Add New Graph…”，把关心的图加入进来，以下图：

 

 

• Analysis
• 合并图的应用

–      有时候看单一的图，很难看出图与图之间的关联，因此这时候，咱们能够采用合并图来进行有机的结合。合并图的方法就是先选择一张合并图，而后在图的空白处单击鼠标右键选择【Merge Graphs…】选项，接着选择被合并图（能够选择合并图类型、能够更改标题），以下图：

 

• Analysis
• 合并图的应用

         合并图共提供了3种方式：叠加（Overlay）、平铺（Tile）和关联（Correlate），下面针对这3种合并方式作一下简单的介绍。

         （1）叠加方式：使得两个图使用相同横轴的图的排列方式。合并图的左侧纵轴显示当前图的值，右侧纵轴显示被合并图的值。

         （2）平铺方式：两个图一个位于另外一个之上，合并图在下方，而被合并图在上方，使得两个图共同使用一个横轴，两个图分别使用搁置的纵轴

         （3）关联方式：使得合并图的纵轴将变成合并图的横轴，被合并图的纵轴将变成合并图的纵轴。