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

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

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

注册流程为：

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

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

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

　　4，服务器验证请求

说明两点状况：

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

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

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

因采用loadrunner11进行的脚本开发，LR11只支持32位的jdk版本，且对jdk的版本兼容性很差，若是采用开发JAVA Vuer类型的脚本，调用封装好的jar包，测须要用一样版本的jdk；

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

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

3、压测及调优过程

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

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网络负载不均衡，参数设置问题；

 

 

以上。