服务端图片图片上传接口性能压测总结

服务端图片上传接口性能压测总结

一。性能测试时需要关注点

        用户操作的相应时间

        服务器资源使用情况是否合理

       应用服务器和数据库资源使用是否合理

       系统能否实现扩展

       系统最多支持多少用户访问、系统最大业务处理量是多少

       系统性能可能存在的瓶颈在哪里

       更换那些设备可以提高性能

       

 

 

二。性能压测需求分析

 

一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

        QPS（TPS）：每秒钟request/事务 数量

        并发数： 系统同时处理的request/事务数

        响应时间：  一般取平均响应时间

        理解了上面三个要素的意义之后，就能推算出它们之间的关系：

        QPS（TPS）= 并发数/平均响应时间    或者   并发数 = QPS*平均响应时间

        一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

 

在原始需求描述中是这样：      

 

                      文件上传：来自小强的Ngix接口

 

                      一天：1个接口 42万，共4台服务器6个接口，42*6=252万个文件

 

                      高峰期1分钟：538个文件，538*6=3228个文件

 

在性能测试方法论中，很典型的方法就是二八原则，量化业务需求。

二八原则：指80%的业务量在20%的时间里完成。

                  按二八原则来计算 (2520000X80%)/(20%X24X3600)=116.6 个请求/秒 ，这个数据是4台服务器的，再除以4 就是 116.6/4=29.1个请求/每秒

                 高峰期 峰值  538*6/60=53.8个请求/每秒

按计算出来的数据，被压测接口 目前的QPS是29.1个请求/每秒，在高峰时能 QPS 53.8个请求/每秒

 

 

三。 环境准备

        1. 被测服务器：因为被测接口是线上真实使用的，不能直接拿线上的测试，要小强单独部署一台 同网络环境，同调优设置的服务器。

                                  208.43.106.202   

                                  24 核 32G

        2. 压测服务器：与被压测服务器是同一网络环境，安装有jdk1.8                            

                                 208.43.106.198 物理机

                                 8 核 8G                                 

        3. 网络带宽：100M

        4. 压测工具：jmeter 2.2.1

        5.jmeter所需第三方jar包：通过实现jmeter基类，实现对被压测接口的调用，把代码编译成jar包，放入jmeter安装目录下的lib/ext目录里

        6. 压测脚本：本地 生成 jmx脚本

        关于第4步到第6步的操作以后放在Jmeter性能测试脚本编写中详细描述

        7.测试数据准备：本次实例中使用的是460K左右的图片文件 

四。初步性能测试

首先，我们来解释两个概念：压力测试和负载测试

负载测试：通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。比如实际中我们说从比较小的负载开始，逐渐增加模拟用户的数量， 直到应用程序响应时间超时，就是说的负载测试。

压力测试：通过逐步增加系统 负载，确定在什么负载条件下系统处于失效状态，以此来获得系统能提供的最大服务级别。

操作步骤：

1. 连接测试服务器   

ssh -p58022 -i .ssh/tanhongbo [email protected]

2. 上传jmeter工具包和测试图片，jmeter脚本

rsync -rave 'ssh -p 58022' --progress  -r upload.jmx  [email protected]:/home/tanhongbo

rsync -rave 'ssh -p 58022' --progress  -r IMG_0084.jpg  [email protected]:/home/tanhongbo

rsync -rave 'ssh -p 58022' --progress  -r apache-jmeter-2.12.zip [email protected]:/home/tanhongbo

3. 将jmeter工具包copy到ec2-user用户目录下（因为权限问题，操作需要在ec2-user目录下执行）

    cp -fr apache-jmeter-2.12.zip /tmp/

    sudo su - ec2-user 

    cp -fr /tmp/apache-jmeter-2.12.zip ./

4. 解压jmeter工具包

   unzip -cv apache-jmeter-2.12.zip

5. 将 upload.jmx和IMG_0084.jpg文件都copy到apache-jmeter-2.12/bin下

6. 执行jmeter的性能测试脚本

cd  /apache-jmeter-2.12/bin   (这里因为执行性能测试是短时间的，所以没把jmeter的bin目录放入环境变量，而是直接跑到jmter的bin目录下执行)   

./jmeter -n -t upload.jmx -l out.jtl >run.log

可以再开一个终端的tab  查看压测执行时的具体日志

  tail -10f run.log

先解释一个概念：吞吐量：默认情况下表示每秒完成的请求数  计算方式为请求数/请求总处理时间

或者是  F=VU * R / T  

其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间

 

在操作时，通过多线程并发的方式来模拟多个用户访问同一请求的情况，我们通过不断加压的方式，从最初的10个并发依次加压，等到100个并发允许10次时，吞吐一直在2.2/s左右徘徊，平均响应时间已经比92个并发时的平均响应时间增加很多，已经出现部分请求因为超时无法得到响应的情况，在·150个并发时已经出现19%的timeout,就是说在100个并发时已经是临界点。而这时的吞吐量只是2.2/s，和我们计算出来要求满足线上要求的29.1/s差距非常大。简单解释一下就是，每秒只能处理完2.2个请求，而线上每秒就要有29.1个请求进来，完全满足不了要求       

性能测试监控关键指标说明：

 

Ø  资源指标

 

CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。

 

内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。

 

磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。

 

网络带宽：一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。

 

Ø  系统指标：

 

并发用户数：某一物理时刻同时向系统提交请求的用户数。

 

在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。

 

平均响应时间：系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。

 

事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务。单位时间内系统可以成功完成多少个定义的事务，在一定程度上反应了系统的处理能力，一般以事务成功率来度量

 超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率

因为首次性能压测时没有获得被测服务器权限，因此没有获取被测服务器的资源指标来做判断。这里可以使用

dstat -cmlnd  命令来获取服务器上 cpu,内存，I/o,网络的数据

上述操作就是压力测试和负载测试混合的测试方式来进行初步性能测试。

五。开发技术方案优化

       从上一步的测试结果得到的数据，当前的负载情况完全满足不了线上用户量的访问。因此 需要开发从代码方面进行优化

      

六。  再次压测

         

          操作步骤：

          1. 再次执行压测        

          ./jmeter -n -t upload.jmx -l out.jtl >run.log

          再次压测后并发测试时的吞吐量 为110/s，已经超过一天的高峰时qps 538*6/60=53.8

 

 2.监控服务器性能数据

 执行命令 dstat -cmlnd

 得到结果， 根据被压服务器 cpu ,内存， load ，I/O, 网络等数据展示，目前 CPU 和内存 还有很大的空间，但网络带宽已经快要占满，目前的瓶颈主要在网络上

 

在测试结果已经满足预期目标的基础上进行了稳定性测试，得到了吞吐率为196.3/S的数据

稳定性测试：亦可称可靠性测试）通过给系统加载一定的业务压力，让系统持续运行一段时间，检测系统是否能够稳定运行。这里进行稳定性测试时一般运行1-3个小时，当时因为网络不稳定，只运行了半个小时。

 

七。 总结

        首先，需要了解性能测试的基本需要，在分析需求后得到性能测试的基本目标数据和峰值数据。其次，准备的测试环境要与线上真实环境一样。最先进行负载测试和压力测试，测试结果满足需求目标的情况下才能往下走，否则就要进行被测服务代码层面的优化。满足需求目标后，再持续压测一段时间，观察被测服务器的各项性能数据是否已达到瓶颈.归纳来说，性能测试就是执行、监控—〉分析—〉调优不断进行的过程，即监控是为分析提供更多的参考数据，分析是为了进行调优，调优是解决当前系统存在的性能瓶颈，为用户提供更好、更快的客户体验