[性能调优]：记录最近一次性能测试项目测试过程

 测试的系统是新上线的系统，为中心系统，对接各类外围系统，预计会员数据在百万级别，此处以“注册”“登录”两个接口举例说明在性能测试过程中碰到的问题，以及解决问题的过程。

一，举例的两个接口很简单，为公司系统的手机注册和登录交易：

注册流程为：

　　1，客户端申请手机验证码

　　2，服务器生成短信验证码后调用短信平台发送短信

　　3，收取短信，提交注册请求

　　4，服务器验证请求

说明两点情况：

1‘，客户端发送给服务器端的信息，先在本地通过三重加密（将json字符串用DES算法加密，加密后用base64编码，发送请求时参数需要UrlEncoder编码） ----------关于加密问题，另起一篇文章讲述；

2’  此处程序版本为性能测试做了点调整，服务器端，只生成验证码后返回给请求客户端，不调用短信息平台发送验证码。

二、脚本开发过程中遇到的问题

因采用loadrunner11进行的脚本开发，LR11只支持32位的jdk版本，且对jdk的版本兼容性不好，如果采用开发JAVA Vuer类型的脚本，调用封装好的jar包，测需要用同样版本的jdk；

尝试过在脚本中直接调用C语言程序的加密代码，但每次的加密过程都需要编译，耗时太长，无法测试；

本次脚本开发过程中，加密的程序是在本地运行，通过http协议访问localhost，通过这种方式，避免了lr不能调用64位jar包的尴尬；

三、压测及调优过程

因本次压测的系统还未上线，所以采用峰值压测方式，看看系统能处理的最大并发能力。

1，注册交易，刚开始采用100用户并发，总会有部分交易报错（10%左右），当采用20用户并发时候，不会报错，成功率为100%，

　问题原因：推测连接池参数有关；

　优化方式：修改连接池参数，解决这个问题；

2，初次压测注册交易，监控到数据库磁盘繁忙度和CPU使用率高，应用服务器CPU超阈值；

    问题原因：通过MYSQL监控，监控到其中一条SQL语句在50秒执行了43000次，而实际的请求事务数，不到7000笔

 

优化方式，；sql语句程序逻辑上的优化，减少查询次数

3，增加硬件资源后，发现cpu使用率最高为50%，响应时间随着并发数增加而增加，服务器的处理能力并未提升，监控后台日志发现发现提交注册请求超时，超8秒以上，后台日志发现注册完成后写数据库很慢，调整数据库连接数20变为100，速度由5秒变为1秒以内

调整前：

调整后：

4，调整数据库连接数后，，发现注册激活业态信息很慢，开发需要从注册的流程上进行优化

优化后结果：

平均时间由3秒多变为0.1秒内

 但是发现LR测出来的结果依然不满意，TPS和之前差不太多，服务器资源也负载不满，思来想去，考虑到可能是带宽的问题（限制了上传下载），

所以多增加一台负载机压测，发现带宽降低为一半，不是带宽的瓶颈

遂考虑是不是在服务器处理请求（输出第一条日志）前，已经开始等待了，试着调整线程池参数，再来一次，陆续发现其他的问题：

5，增加用户数之后，事物响应时间也随之成正比增加，TPS基本稳定在200左右；试着抓了一次资源信息，发现了一个磁盘的问题：

,

可以看到保存数据信息，导致磁盘写繁忙度达阈值，实际上是因为这个数据库服务器部署在虚拟机上，本省的磁盘读写速度就很慢，和环境组沟通后，重新申请了物理机，部署。调整后，看到磁盘读写能力大大提升了，如下图：

提升速度已经很明显了，果然发现TPS有一定幅度的提升，但还是没有达到目标，

6，后面的优化，实际上也没有发现什么问题：和开发沟通后，因为是注册保存数据较慢，考虑到redis内存存储信息，加快保存数据处理

采用redis存储之后，压测，好像依然没有改善，后面分析超时日志信息，发现问题在操作redis时计算分片的函数耗时较长

7，优化计算redis分片函数之后，性能直接提升到了1000了，

监控服务器数据，又发现一个问题：

数据库中间件Mycat第一台的网络负载压力较大，26M/秒，原因是负载均衡问题，配置问题，小问题，修改后验证。

至此，这次的测试算是达到目标了，测试任务完成了，

本次经验总结：

1，环境准备：因本次测试的指标目标较高，对个方面资源的性能要求较高，在CPU、内存、磁盘、网络，负载机，个方面准备需要提前；

例如负载机的问题，因为本次压测数据吞吐量较高，如果没有提前申请和服务器同一网段的负载机，后面进行压测历史的话，网络就会限制，在同一网段的负载机上压测，网络问题就基本可以忽略；

2，脚本开发：本次注册的脚本，发送请求信息，在客户端都有一个三重加密步骤：UrlEncoder.encode(Base64.encode(DES.encrypt(jsonStr, key)), "utf-8")；

加密的jar包需要开发提前提供；

其次，注册需要发送手机验证码，在生产的版本，会对手机号格式校验，以及发送真是短信到手机上，这样在脚本中是跑不了的；

所以需要对程序版本进行一定的修改：1，不校验手机号格式，2，不真实发送手机短信，短信验证码包含在申请验证码的返回报文信息中；

3，压测调优过程：

1）200用户并发时，部分交易报系统错误，调整线程池参数，增加线程池连接数；

2）数据库慢查询监控，将耗时较长的sql语句挑出来优化；

3）数据库语句监控，例如监控到一次交易中，多次反复执行的sql语句，从代码的执行逻辑上优化，减少sql语句执行次数，较少代码开销

4）监控硬件资源，在硬件资源产生瓶颈之后，提升内存和CPU的资源；

5）增加用户并发数，提高服务器日志级别，将耗时较长的交易流水找出来，逐条分析日志，定位耗时较长的函数，发现保存用户注册信息较慢，优化数据库连接数参数；

6）原本为了方便，是用本地负载机做的压测，当网络传输数据量到达一定时，本地负载机的网络成了瓶颈，遂换到和测试环境同一网段的远程机上做压测；

7）继续压测，发现注册保存用户信息仍然较慢，监控到磁盘繁忙度较高，了解到测试环境数据库部署到的虚拟机上时，处理能力较差，遂申请更换物理服务器，提高磁盘读写能力；

8）到硬盘读写能力和网络能力提升之后，处理能力并无本质提升，开发考虑才有redis内存保存的方式，提高存储速度，压测后略微有提升；

9）监控后发现，在写redis内存块，处理速度较慢，分析为操作redis时计算分片的函数耗时较长

10）监控数据库中间件Mycat网络负载不均衡，参数设置问题；

 

 

以上。