性能测试的一些概念和技巧分析

1、一些性能测试概念不同概念的用户系统用户：可以连接并使用系统的用户。比如一个单位使用某系统办公，每个人都用， 这个单位有500人，那么这个系统的总用户数就是500。同时在线用户：当前已经连接系统的用户； 但他们不一定对服务器构成压力， 比如正在浏览 信息的用户，正在填写表单的用户， 这部分用户不会对服务器造成压力； 只有并发用户才会 对服务器造成压力。并发用户：当前正在与服务器进行交互的用户，他们会对系统造成压力，比如正在向服务器提交查询数据的用户，正在提交保存表格的用户。并发用户数的统计方法目前并没有准确的公式，因为不同的系统会有不同的并发特点。例如OA系统统计并发用户数量的经验公式是系统用户

2、数的5%20%。对于这个公式是没有必要拘泥于计算的结果，因为为了保证系统的扩展空间，测试时的并发用户数量要稍微大一些， 除非是要测试系统能承载的最大并发用户数量。虚拟用户：性能测试工具（如 LoadRunner ）通过某种仿真机制虚拟出来的用来仿真现实用 户行为的用户，模仿的可以是同时在线用户，也可以是并发用户。测试类型基准测试：通过测试建立一个已知的性能水平基线，当场景或者环境发生变化时，用这时候的测试结果来和基线进行对比，确定变化因素对系统的影响程度。比如我们在进行多用户并发测试之前，先用单用户执行测试并记录结果，作为性能水平基线； 在多用户并发测试后，用得到的结果与基线对比，就可以看出用

3、户数对系统性能的影响。一般性能测试：模拟现实中日常的并发数或者访问量的场景进行的并发测试。 峰值测试：模拟现实中可能出现最大并发数或者访问量的场景进行的并发测试。比如一个网站某月的日平均访问量为10万，X日那天的访问量最大，达到 20万，那么10万访问量就是一般性能测试的指标，20万访问量就是峰值测试的指标。OA系统的峰值估算可采用：C+3*根号C,其中C就是一般性能测试时的并发数；当然，这个是根据概率论里面的泊松分布推算出来的，自然也不是准确的；如果能有系统确切的历史数据或者类似系统的参考数据，这样是最好的。压力测试：通过不断增加系统负荷（比如并发用户数），测试系统什么在时候失效。负载测试：

4、让系统在超负荷环境（比如非常多的并发用户，或者非常多的数据）下运行，测 试系统是否能承受住。容量测试：在满足性能指标的前提下，测试系统最大可以支持多少并发用户。稳定性测试：在最一般的负荷下，长时间运行系统，查看是否会出错。举个形象的例子，假设我有一头驴子来从集市往家里驮东西，平常一般就买50斤东西，最多的时候也不超过 100斤，从家到集市大概有10里，我自己走大概要 1小时。般性能测试：让驴子驮 50斤东西往家走，看它能走多快。峰值测试：让驴子驮 100斤东西往家走，看它能走多快。压力测试：10斤20斤50斤100斤150斤”不断往上加，看这驴子啥时候被压跨了。负载测试：让驴子驮 200斤东西

5、往家走，看看它能不能坚持住。容量测试：我希望驴子能完全跟上我的速度，在这个标准下，驴子最多能驮多少斤。稳定性测试：让驴子驮 50斤东西走50里路，看它能不能坚持住。性能拐点分析基本思想是，当系统中某个资源的使用达到了极限时，随着压力的增大，系统性能却出现急剧下降，响应时间显著增加，这样就产生了拐点现象。F面这张事务平均响应时间图很好的反应了拐点现象（来源为自动进口许可证性能测试,景设定是从5虚拟用户开始，每5分钟加载5个虚拟用户最多加载到 100虚拟用户）：当虚当虚拟用户60个虚拟拟用户数不超过 40的时候，事务的响应时间几乎没有随虚拟用户数的增加而增加；当虚拟 用户数在4060的时候，事务的

6、响应时间随着虚拟用户数的增加而有小幅增加； 数高于60的时候，事务的响应时间随着虚拟用户数的增加而有显著增加。于是，用户就成为了该场景中系统的性能拐点。1C-Average Transactlcn Response Time唁nx $3麼 0 Ou 4a 4i 屯咽 3KJ：1fl：QOra：Zfl：0QOD：3JQMQO：4Q1M100:50:00Q1 ：3QOTElapsed scenario time hhmm而什么原因造成了这个性能拐点的出现？我们发现CPU记录图出现了如下的情况:%事遇j 1 71 H (U F ScalezJMeaisiTiisrtMGrh*$ 阳G “： 5 id

7、. i93上抿1,1工玄蓟:诫 41.04 曬僦 皿:即 O+K05:阅開.閒07 00 他即1D.M 11.M1213:D0140415.MElagMd 主口申n期口 timt mm $Leoirtd它戏唯处皓|也-J | LJ壬f尿Co ”| Graph*T |&iatfh-*Met 专|g仲也阚、|EI1文辛页aol395IK0,4062.177丽曲Ed121底11D.GG4D.2P123Q22SD.15B很明显，系统的性能拐点为 30用户，查看CPU、内存的记录，并无异常；而再看一下吞吐 量的记录，呈现出下面的现象：H.SDD-MC13 W1 -|上负砂 ii.DW.se：10 M Q

8、QQ 蓍口.0玄学苗15M3; DK ：-；1 Cd T ；.： |wca5iiien-ierlt jGriqph Mininun l/eiage* |Guph Majjnum | Graph Mieduri |GrhSld。曲凶kr 0lotHmaes1510612&41151D957|H252E4EIDiUQCHOODOW D122030 KK KM D7W B1011K1204L 四 tnd吧宓叫鈕迟空T I玉I亚I EJspsed cerurio time iwn:s4很明显，在超过 30用户后，系统的吞吐量就不再有明显的增加，而测试环境中使用的是 100Mbps的网络环境，理论上即约

9、为 1200多万字节每秒，这恰好与图中的数值相合，所以 带宽瓶颈是导致性能拐点出现的原因。由于压力机端的带宽和服务器端的带宽可能是不对称的，比如压力机端只能使用100Mbps，而服务器端则可以使用IGbps，这就会使压力机端产生带宽瓶颈，对测试结果造成影响；因此在进行性能测试的时候，压力机端的带宽要尽可能大，尽量降低压力机端带宽瓶颈对测试 结果的影响。常见系统类别信息发布系统（如各种网站）：（1 ）用户范围不确定，用户数难以统计（2）系统的主要操作集中在页面访问、信息查询、信息发布（如留言、评论等）（2）图片等资源请求较多，所以网络带宽对测试结果通常影响较大信息管理系统（OA系统）：（1 ）用

10、户范围是比较确定的，用户数较容易统计（2）通常系统的业务功能会很多，但是只有其中一部分业务功能是最常用的，其他功能的 使用相比起来会少很多（3）很多情况下，主要业务功能的执行在时间上会有一定的特点（4）图片等资源请求较少，所以网络带宽通常来讲对测试结果影响不大测试角度客户端角度：模拟同时在线用户特点：直接体现现实中的操作场景，测试结果在用户层面上非常直观，但是需要详细了解用户的操作习惯，并在编辑测试脚本时体现出来，否则测试结果的说服力不强 服务端角度：模拟并发用户特点： 不需要了解用户的操作习惯， 但不能体现现实中的操作场景， 测试结果能反映服务器 处理能力，但在用户层面上不够直观 测试需求分

11、析常见的测试需求有：（1）测试事务，脚本录制的基础，必须有（2）并发用户数，场景设置的基础，必须有（可以是直接给出来的，也可以是计算出来的）（3）平均响应时间，最基本性能指标，必须有（4）业务量，一些系统需要验证能否支持；另外当没有给出并发用户数时，可以使用业务 量和平均响应时间计算并发用户数（5）事务通过率，必须有，因为事务出错过多对系统而言是不可接受的（6）用户使的用网络带宽（7）服务器资源占用，建议给出示例 1：某个网站，在页面访问的平均响应时间不超过8 秒的情况下，测试服务端最大能够支持的并发请求数；测试中并发请求上限设定为200（性能探索，服务端角度）示例 2：某个业务系统， 300

12、 用户同时在线执行 XX 操作，平均响应时间不超过 8 秒（性能 验证，客户端角度）示例 3：某个业务系统中，在平均响应时间不超过5 秒的情况下，测试系统可以支持的同时在线执行 XX 操作的最大用户数；预计在项目周期内，同时在线用户数不会超过600（性能探索，客户端角度）示例 4：在某个业务系统中， 业务 A 的处理时间集中在每月最后 4 个工作日， 每个工作日以8 小时计，每月执行的业务 A 数量可以达到 36 万笔，业务 A 完成的平均响应时间不能超过8 秒（性能验证，服务端角度）测试场景中能够控制的是并发用户数，而在示例1、2、3 中都包含了并发用户数的信息，但是示例 4 中却没有并发用

13、户数的信息，为了测试需要我们需要自己计算并发用户数 依据 80-20 原则进行计算，系统对业务 A 的处理能力，即每秒业务数 M 需要达到： 360000*0.8/（4*8*3600*0.2）=12.5 笔 /秒假设测试时间为 T,测试时间内执行的业务总数为N,那么每秒业务数 M=N/T假设平均响应时间为t，那么可以视作所有用户每t秒完成一笔操作，假设并发用户数为n,那么又会有 N=n*T/t ，则有 M*T=n*T/t ，于是又有 M=n/t因为M的临界值是12.5, t的临界值是8,那么可取12.5*8=100为并发用户数，如果测试结 果中平均响应时间不超过 8秒，那么每秒业务数必然可以达

14、到12.5笔/秒测试场景典型场景： 在现实中最具代表性的场景, 使用典型场景的测试是对实际情况的最好模拟, 具 有非常强的说服力 示例：商务部手机政务系统,常用功能包括获取公告、会议通知,以及手机报浏览,压力主 要体现在如下场景：1、当对某些用户有新的公告发布时，这些用户会用客户端同时获取公告2、当对某些用户有新的会议通知时，这些用户会用客户端同时获取会议信息3、当有新的手机报发布时，在短时间内所有的用户都会用客户端获取手机报典型场景通常和时段的密不可分， 由于时段的关系， 在典型场景中经常会出现多个事务的混 合，比如在服务外包系统中， 典型的场景为企业用户集中在每月最后 7 天进行合同新增上

15、报 （每月 XXX 笔）以及合同执行保存（每月 XXX 笔）；网站系统中的典型场景，经常是在 同一个时段内，包含网页浏览（包括首页、栏目页、文章页等）、信息检索、信息提交（如 发布留言、评论等）操作都有执行 如果典型场景是多个事务的混合，需要分别为每个事务分配操作用户数另外，为了找到哪个事务更容易造成服务器瓶颈，单一事务的场景通常也需要测试测试脚本编辑这个不多说了，只说几点：1、如果多个事务明显具有一定的流程性，建议作为一个整体录制在1 个脚本中，这样既能体现业务场景，也方便使用关联操作2、录制脚本看的是使用的协议，而不是展现的形式，因为LR 不会管系统是用客户端程序还是 Web 端程序；比如

16、对于手机客户端，显然这个用 LR 录制脚本是不可能的，但是如 果客户端请求是基于 HTML 协议的， 那么同样在 PC 机的浏览器中也是可以发送请求并 接受返回信息的3、基于 Web 浏览器的性能测试， 常用的录制模式有 HTML 模式和 URL 模式；前者类似于 先建立一个文件目录，然后再按照目录来请求其中的资源，但是如果请求的资源中存在 可以自动执行的 JS 文件之类的话，是记录不到该文件自动执行时所执行的请求；而后 者则是只要有任何请求， 都可以在脚本中记录下来； 如果页面中的某些操作使用 HTML 录制不到，一般更换成 URL 模式进行录制就可以了（除非选的协议有问题）4、URL 模式

17、虽然能录制到所有的 HTML 请求，但是这种模式会大大增加脚本的代码量和 复杂度，很不易于编辑维护，所以还是要尽可能用 HTML 模式进行录制5、对于非 HTML 的请求， 那么录制时就需要选择其他协议， 通常还需要自己编写脚本实现 请求的发送和接受6、少量基于 HTML 协议的请求的头信息中， 会包含一些比较特殊的内容， 而 LR 虽然能记 录到，但是在回放的时候却不会使用，于是这样录制下来的脚本在回放时是无法获得正 确的返回信息的；需要对比录制时和运行时发送的请求的头信息，手动用函数 web_add_auto_header 添加7、脚本试运行通过只是说明 http 返回值没有问题， 但并不

18、能校验返回结果是否正确，所以 必须设置相应的检查点，一般说来像登录、保存、删除、查询之类的操作都要设置检查 点进行校验8、脚本调试通过，检查点也没有问题，并不能代表脚本就没有问题了，特别是对于使用了 参数的脚本， 因为脚本调试只会使用第一个参数值， 然而并发时会同时使用多个参数值； 因此脚本编辑完成后，必须在场景里面进行一下少量并发用户（如 5 个）的试运行9、我们可以用页面上有代表性的文字来作检查点，同样我们也可以用页面上那些直接看不到的链接10、一些不能够进行常规参数化的地方，可以用其他的方式完成参数化举个例子， 我们要随机使用某几个身份各不相同的用户中的一个登录系统， 而系统中登录发送的

19、请求除了参数化的用户名和密码之外都是一样的， 登录成功之后， 系统会根据用户的身 份来显示不同内容的页面显然我们在设置事务时需要考虑不同的身份的用户， 比如管理员登录的事务我们可以记录为 “管理员登录”，操作员登录的事务我们可以记录为“操作员登录” 往往我们直接会用事务函数lr_start_transaction（ “ ”），但是引号中间的内容是无法被参数化的， 所以通常我们的解决方法是分别在不同的 action 中使用不同的用户登录， 再用 不同的事务名称分别标记，比如 lr_start_transaction（ “管理员登录 ”） lr_start_transaction（ “操作 员登录

20、”）；然后在一个block中加入这几个action，然后设置这几个 action之间的关系为随 机选择 但是，如果我们在脚本中这样建立三个参数：第一个是username 代表用户名，第二个是password 代表用户密码，第三个是identity 代表用户身份，在三个参数的每一行分别记录一个用户的用户名、 密码和身份， 并且设置参数随机选取， 并且每次循环是几个参数都读取同 一 行 （ the same line as ） ， 那 么 我 们 就 可 以 把 事 务 函 数 写 成 lr_start_transaction（lr_eval_string（ “identity 登录 ”），这样我

21、们只在一个 action 中就可以实现场景运行时的常见问题和原因1、报错：连接服务器失败，或者服务器过早的关闭了连接 可能原因：（1）应用服务器死掉了 （2）如果应用服务器没有死，那么可能是应用服务参数设置有问题（如配置的最大连接数 太少），或者数据库方面的问题（如程序中执行了效率很低的语句）2、 事务响应时间很长，甚至报超时错误（超时默认是120 秒） 可能原因：（1）如果吞吐量已经达到了网络环境中的带宽上限，那么就是网络瓶颈（2）压力机的实际连接速率低于服务器，比如整个网络环境是千兆，服务器实际连接速率 可以达到千兆， 而一台压力机的实际连接速率只能达到百兆， 如果只用一台压力机测试就容

22、易出现这个问题； 使用多台压力机分摊并发用户可以避免这个问题 （如果由于限制， 压力机 所在的局域网连接服务器只能达到百兆，那就没办法了）（2） 页面中存在太多或者太大的资源，比如好几MB 的图片之类，通常这些问题会出现在 网站首页，需要对页面资源进行优化（3）如果确实存在较大的资源（如视频之类的），而这个资源却又是必须的，那么应当增加响应时间上限值（默认是120 秒）（4）存在发往非测试服务器的请求，通常都是公网的，因为测试机连接公网的速度很慢，所以并发时自然会拖慢响应时间； 其中有些是在脚本中可见的， 可以直接屏蔽， 而有些则是 脚本中不可见的隐藏请求，那么要在脚本运行设置中过滤掉相关的U

23、RL （脚本调试的时候可以发现那些隐藏请求的URL ）（5）如果是检索查询类的请求，那么很可能是因为数据量过大而又没有建立索引，导致查 询效率低下，通常在数据库建立索引可以解决问题（6）部分服务器（特别是虚拟机）进行了带宽限制（7）也有可能是应用服务的配置参数有问题，比如JBOSS的AJP最大连接数太小3、系统使用了多台服务器进行负载均衡，但是场景运行时监控这些服务器，发现只有其中 一台服务器有压力，而其他服务器没有压力可能原因：负载均衡策略是按IP进行压力分配的，如果一个IP发送的请求首先分给了服务器A，那么之后源自这个IP的请求都会由服务器 A进行处理；由于通常情况下测试过程中产生的并发

24、请求只会使用一个或者几个IP,自然就很容易造成某一台服务器有压力，而另一台服务器没有压力的情况；更改负载均衡策略即可解决问题服务器资源的异常Linux系统下，可使用 vmstat命令查看并记录服务器资源数据使用举例：vmstat -n test.txt 3 500这条命令就是表示在当前用户的根目录下，建立一个文件名为test.txt的文件，在其中每隔3秒记录一次，最大记录500次；文件中的记录如下：memory- K SpStPR-=匸卩11匚1 =二rbsupdfreebuffcachesi sobiboincs usid waQ002 039S8Q18200038O2SO0000Q0000

25、1000a0920392921820Q0380250000079208*121l519400002038S88182000380276000010412屿379109800802O37SO0182000380276S000B11201921099010020372438035400001332527143719201002 037521820OQ38035400002432226882旳1950100203622 El18200038O3Sik0000016SS49120980Q0D18200038D38D000012313159 0830960000202871618200Q38D38DB0

26、000讪351311118801002028S80182000380406 0000他156261130970009202781218200038045800001852849183H7192c000202737218200Q38B458Q0004239593期7122876000202724418203038OUS8009028810408Ca010000092 024356182000380458000002 01068 081328500002 023 01218200838O510Q0813212153 as16996000202269218203938051OQ000113142l4

27、81109902092 9221801820093805A2S000B22 031630101890000202160418200838064D0080291296515958191C0002 021iH218200038064000000116425310990常见的服务器资源异常的表现：1、如果空闲CPU时间（cpu下的id）持续低于20,那么应当引起注意2、 运行和等待运行的进程数（procs下的r）如果持续超过服务器 CPU的核心总数，那么 就会出现CPU瓶颈3、 可用内存数（memory下的free）较低，虚拟内存使用的大小（memory下的swap）总是 大于0，并且虚拟内存交换区

28、的读写（swap下的si和so）总是大于0，那么表示内存不 够用了，或者是出现了内存泄露，或者是该升级内存了4、 块设备每秒读写的块数量（io下的bi和bo） 般都要接近于 0，如果持续较大，并且等 待10的CPU时间（cpu下的wa）持续不为0,那么说明磁盘10过于频繁页面资源分析公网发布的网站系统中，页面大小通常会成为影响用户访问响应时间的主要因素，我们可以对访问页面的事务进行web page breakdown处理，从而查看页面中每个资源的响应时间细分图，从中查找响应时间过长的资源，并进行简要分析12J12.ee. ,13421fcwfLpg 12312.et.(E02l0aSflM12312.ec.08S0&nsE3.ipg 12312. .ing/dcwilwd&png12312. . d帰hu缈1.j$ 12312 eQ.12083fc6j2.P 叩12312. .Ji