关于压测的部分总结

关于压测的部分总结

1、hystrix配置

Hystrix（断路器）的主要作用是服务降级，服务熔断，依赖隔离等功能，服务启用了Hystrix则会按照它的规则进行处理

Hystrix设置默认为10，如果并发超过10之后会对服务进行降级，没有做降级策略的话就会报错，所以压测的时候会异常率增大，需要调整并发数来解决此问题。

Hystrix调整并发访问量方案重要的两个参数如下：

coreSize:并发执行的最大线程数，默认10

maxQueueSize:线程池最大等待队列

不同服务根据各自职责进行不同设置

• gateway负责服务路由管理，auth服务负责用户登录，都是比较常用服务，此处值可以设置大一些，

  coreSize:100 maxQueueSize: 300， 能够满足用户400并发访问

• mdm-model、base、flow等并发量不大的服务可以将并发量设置偏小点

  coreSize:50 maxQueueSize: 150， 能够满足用户150并发操作

hystrix:
  command:
    default:
      execution:
        timeout:
          enabled: true
        isolation:
          thread:  #启用线程
            timeoutInMilliseconds: 220000  #超时时间
  threadpool:
    default:
      coreSize: 100
      maxQueueSize: 300

2、ribbon配置

ribbon负责服务的负载均衡，以及连接超时、重试等机制设置。

在主数据平台中，会有一些操作如500条数据提交，导入数据时需要长时间的服务连接，ribbon的超时设置也是根据具体的服务职责设置时间大小：

• mdm-model、flow、mdm-esb等服务耗时比较多可以设置较大些

  ReadTimeout: 120000 ConnectTimeout: 30000

• base、auth等服务耗时不多可以设置较小些

  ReadTimeout: 40000 ConnectTimeout: 20000

此处需要注意的是设置ReadTimeout、ConnectTimeout、MaxAutoRetries、MaxAutoRetriesNextServer参数需要同时修改hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds属性，具体计算规则如下所示：

timeoutInMilliseconds>= (1+MaxAutoRetries) * (1+MaxAutoRetriesNextServer) *(ReadTimeout+ConnectTimeout)

套用如下文件设置规则则是：

180000>=(1+0) * (1+0) * (60000+30000)

ribbon:
  ReadTimeout: 60000  #连接保持时间
  ConnectTimeout: 30000  #建立连接时间
  ServerListRefreshInterval: 5000 #刷新监听时间
  MaxAutoRetries: 0   #当前实例重试的次数，失败之后更换下个实例
  MaxAutoRetriesNextServer: 0  #更换实例的次数
  
hystrix:
  command:
    default:
      execution:
        timeout:
          enabled: true
        isolation:
          thread:  #启用线程
            timeoutInMilliseconds: 180000  #超时时间

3、数据库配置

在压测时有些时候会报数据库连接超时的错误，次数需要注意的是：

• 如果确实执行sql庞大执行缓慢，则需要调整connection-timeout ,目前所知mdm-model、flow服务需要调大为120000 ，其余服务正常20000就能满足需求
• 如果执行sql不大且执行缓慢，需要排查数据表索引问题，看查询表中的相关字段是否添加索引

spring:
  datasource:
    hikari:
      connection-timeout: 120000
      idle-timeout: 300000
      max-lifetime: 150000
      minimum-idle: 5
      maximum-pool-size: 100

4、nginx配置

在压测保存数据320并发时nginx会报错（当前页面不允许）

需要调整相关参数，可以根据情况来设置线程数

worker_processes  4; #设置线程数
http{
    keepalive_timeout  65; #保持连接打开时间
    proxy_connect_timeout  600s; #连接超时时间
    proxy_send_timeout  600s; #发送请求时间
    proxy_read_timeout  600s; #接收请求时间
}

5、Redis配置

如果涉及到redis业务多的话可以调整redis的连接数

redis:
  pool:
    max-idle: 50  #连接池中的最大空闲连接
    min-idle: 10  #连接池中的最小空闲连接
    max-active: 50 #连接池最大连接数（使用负值表示没有限制）
    max-wait: -1 #连接池最大阻塞等待时间（使用负值表示没有限制）

6、内存配置

• 系统内存

  • 查看系统剩余内存及使用情况

    # -h: 单位G  -m: 单位M
    free -h
    # 查看使用情况
    top
    

• 程序内存

  • 调整程序运行内存

    # -Xms2048M -Xmx2048M 调整最小内存、最大内存大小
    nohup java -Duser.timezone=GMT+08 -Dfile.encoding=UTF-8 -Xms2048M -Xmx2048M -jar xxx-service-1.0.0-SNAPSHOT.jar > start.log 2>&1 &
    

• 句柄数、最大进程数

  • 查看参数

    # 查看最大文件句柄数
    ulimit -n
    # 查看最大线程数
    ulimit -u
    

  • 修改参数

    # 修改最大文件句柄数
    vi /etc/security/limits.conf
    # 在最下方添加, *代表所有用户
    * soft nofile 65536
    * hard nofile 65536
    * soft nproc 65536
    * hard nproc 65536
    

    # 修改最大线程数,最后面的文件不固定，以机器实际配置为准
    vi /etc/security/limits.d/20-nproc.conf
    # 在最下方添加
    *          soft    nproc     65536
    root       soft    nproc     unlimited
    

7、其他

• 性能提高： 保存数据时自动生成编码，由于需要控制编码不重复，所以在编码处添加锁，锁内的业务处理由于与数据库交互较多，所以高并发的时候线程等待时间太久，会导致性能下降，针对这种情况锁内的代码业务部分涉及的数据可以存入redis中，然后后面可以启用定时等功能来同步至mysql数据库中，此种性能经测试可以提高10倍性能以上
• 死锁： 查询和更新同一批数据时，会发生锁循环等待，从而产生死锁，解决方法为 减小锁的粒度，细化查询条件和更新条件，尽量精确到某个或者某些id进行操作，不使用全表操作
• 测试优化： 使用Jmeter测试时有些场景需要其他条件来配合，比如数据审核场景就是需要先查询出待审核数据之后再对数据进行审核，但是查询待审核数据也是相当耗时，这个时间也会统计到总时间内，其实这是非必要统计时间，可以使用Jmeter直连数据库的脚本来减小查询待审核数据的时间
• 统计日志： 高并发测试监控性能时注意打印日志格式（非常重要，节省很多时间），最好将关键信息整合之后进行统一打印，需要计算出步骤的耗时时间，方便进行日志分析，因为高并发情况下打印日志是海量的动辄几十万条，在程序中连续打印的日志在此时不一定连续，查找起来很难找、耗时。
• cpu、内存： 注意压测时要注意cpu、内存的试用情况，正常情况高并发下cpu利用率、内存会增大，如果高并发下cpu利用率、内存变化不大的话就需要分析下是否程序问题