Skip to content

Latest commit

 

History

History
41 lines (20 loc) · 4.62 KB

14-1-性能测试怎么测试.md

File metadata and controls

41 lines (20 loc) · 4.62 KB

14-1-性能测试怎么测试

性能测试其实就是通过自动化工具模拟多种正常、峰值以及异常负载来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,二者可结合使用。

性能指标主要有平均响应时间、90%响应时间、吞吐量、吞吐率,每秒事务数,以及服务器的资源使用率(CPU占比,mem内存占比等)等。当并发用户数超过300时,为了让测试数据更准确,可以考虑分布式压测,通过jmeter客户端控制几台jmeter服务器进行测试。

性能测试要先调试好脚本,主要考虑对脚本的数据参数化和添加断言。因为有些接口需要对业务逻辑或参数格式进行校验,为了能让所有线程数跑起来,需要将数据参数化。

数据参数化有这几种做法:

1、可以将一些固定值改成随机函数;

2、利用JDBC从数据库读取数据并关联变量;

3、Excal数据参数化,

4、动态关联参数化,断言是为了判断用例是否

执行成功,并验证服务器的响应错误率。响应断言常用json断言,xml断言用的最少,

性能测试的目的是为了检验系统能否满足客户的性能需求,若性能需求无法满足时,则

要考虑对系统进行性能调优,一般用排除法:

1、首先考虑网络方面问题:使用ping命令查看与目标服务器的连接是否正常、传输速度的快慢。通过提升服务器的带宽,看响应时间是否相应降低。

2、考虑数据库的问题,可以单独去压测数据库,查看数据库的最大连接数和SQL语句的执行时间,索引命中率和sleep等待时间等

3、考虑 Apache/Nginx等中间件的问题,查看中间件设置的最大连接数是否合理,如果设置的连接数太小,会话数超过设定的最大连接数时会导致等待时间变长,出现响应超时情况

4、考虑服务器的硬件配置,如内存、CPU、磁盘读写速度等,可以用top命令来监控,也可以使用nmom工具来监控,nmom会把监控的数据形成表格形式,方便我们查看。

5、最后考虑开发代码写的好不好,处理时间长不长的问题。

举例:在我之前的公司,我们主要是会考虑用户操作使用比较频繁的模块,比如借贷,充值,投资模块,我们一般会通过增加并发数来压测,观察CPU、mem、磁盘读写、吞吐量和每秒事务数等性能指标,以前我老大要求我并发100个用户,我用 jmeter把线程数设为100,永久循环,持续时间半个小时,设置启动延退55,在Linux启用mmom工具监控服务器。

当我运行脚本的时候我看聚合报告90%的平均响应时间达到了6s,吞吐量也比较小,用top命令监控资源发现CPU差不多到了100%。于是我用 Navicat工具通过SQL命令show full processlist取当前运行的SQL语句,发现有许多语句用的是左关联,在查看了这条SQL语句的执行计划发现没有用索引,再查看了索引的命中率,命中率倒是还行看了下nmom生成的报告,发现CPU一直是处于爆满状态,其中主要是mysql的占比很大,这个时候我基本上判断数据库的问题。

于是我就照着前面的步骤再次压测,同样还是用nmom工具去监控CPU,mem网络等状态,这次我是主要在 Navicat上用命令去抓取SQL语句,还是一样有很多语句都是左关联,并发现很多空连接(sleep),我就用 show global variable like"wait_time"命令查看了设置的休眠时间(等待时间)发现时间很长28800s,然后我就把这个休眠时间改成了20s,因为SQL语句使用了很多左连接,我就用 show variables like"tables_size"查看了临时表的空间大小、发现临时表只有16m,我将空间改成了1G再去压测了下,发现CPU只是降了10%左右,nmom报告上还是显示mysql占的CPU很大,然后运行的时候,用top命令监控,发现有的时候有很多mysq进程同时运行(因为没有设置连接池),我就用命令查看了下mysql的最大连接数,因为SQL语句的执行速度还是挺快的,所以就把mysql的连接数调小到50,再去跑了一遍发现CPU降到了40%左右,并且其他的性能指标也都还不错。最后把聚合报告的数据以及nmom的数据整理成性能报告给老大,其实做接口性能主要就是用排除法个一个去排除,发现性能问题就要先解决了性能问题再压测,不然其他的问题也有可能是这个性能问题导致的所以接口性能基本上就是观察,各个性能指标都在范围之内就差不多了。