码迷,mamicode.com
首页 > 编程语言 > 详细

记一次Spring Cloud压力测试

时间:2018-08-24 22:50:41      阅读:303      评论:0      收藏:0      [点我收藏+]

标签:平台   最大的   ali   方向   span   hystrix   erro   一个   通过   

前言

       公司打算举办一场活动,现场参与活动人数比较多。针对于可能访问比较密集的接口进行压力测试。使用jmeter进行测试,请求并发稍微多些,系统就会挂起。

  针对压力测试出现的问题,因为并发超过1秒钟100笔就会出现问题,Spring Cloud作为一个成熟的框架,不可能是框架不支持。所以首先想到的是配置上需要进行调优。

1、Spring Cloud配置调优

  请求从jmeter发出后,需要通过Zuul网关,然后到Spring Cloud微服务端。所以,整个调优方向分为两个地方:微服务端和zuul网关。

1.2、微服务应用

  当jmeter调整到每秒钟70个并发请求时,服务应用端的日志中出现了很多hystrix回滚,并且有很多HystrixRuntimeException。

com.netflix.hystrix.exception.HystrixRuntimeException ... could not be queued for execution...

  原因:Hystrix请求线程池缺省为最大10个线程,在大量请求下,很容易超过这个数值,导致抛出异常。

  解决方法:在配置文件中修改线程池中的coreSize(properties方式的配置文件)

hystrix.threadpool.default.coreSize=500

  配置上测试后,客户端不再出现hystrix的异常了,但是并发请求数进一步提高到100以上后,依然会无法响应请求。

1.3、zuul网关

  由于网关也配置使用了Hystrix,在并发请求过大时,也会抛出异常:

com.netflix.hystrix.exception.HystrixRuntimeException: ggx-test short-circuited and no fallback available

  显示的异常时,具体的ggx-test服务系统短路并且没有熔断可用,但ggx-test系统还正在运行,所以问题出现在zuul网关上。

  ① zuul内部路由可以理解为使用一个线程池去发送路由请求,所以我们也需要扩大这个线程池的容量。

zuul.host.maxTotalConnections=1000
zuul.host.maxPerRouteConnections=1000

  ② zuul使用Hystrix,而Hystrix有隔离策略: THREAD 以及 SEMAPHORE ,默认是 SEMAPHORE ,默认大小是100。请求的并发线程超过100就会报错。

zuul.semaphore.max-semaphores=5000

  配置完上述配置后,重新进行测试,在日志中不会出现错误了,但是并发请求超过100/S时,系统挂起,不再响应请求。于是,排查各种可能后,想到了可能是数据库连接池的问题。

2、数据库连接池

  我们系统使用数据库连接池是c3p0,最大的数据库配置的连接数为30个,尝试将数据库最大连接数修改到100时,使用jmeter测试,并发请求能够稍微提高些。这样能够定位到问题就在数据库连接池上。

  目前市场上主流的开源数据库连接池有:C3P0,DBCP,Druid,HikariCp。其中C3P0和DBCP是出现的比较早的数据库连接,比较稳定,在低并发的情况下,整体表现还不错,但是在高并发下,响应时间变长,性能很差,甚至于死锁。Druid是阿里巴巴开源的高性能数据库连接池,虽然性能不及HikariCp,但是它提供的各种维度的统计分析的功能,在国内市场流行度很高。

  相关的数据库连接池对比:

 

C3P0/DBCP

Druid

hikariCP

应用

主要在Hibernate

 各大主流平台

起源于boneCP

性能

较差

很强

线程池容器

Blocking Queue

List Reentrantlock

 

  综合,Druid性能比较优异,网上文档资料很健全,加上可视化的统计分析很适合我们解决当前问题。我们将数据库连接池从C3P0换到了Druid。

3、总结

  经过上面优化,压力测试达到了预期,jmeter每秒钟发送1000个并发请求,系统能够在预期时间内顺利返回响应结果。虽然不是很高,但是应对我们当前业务需求是足够的。没有最优的架构,只有最合适的架构,一切系统设计原则都要以解决业务问题为最终目标,脱离实际业务的技术情怀架构往往会给系统带入大坑。当然这并不能影响我们对技术的追求,在碰到并发请求大的情况下,有几个维度可以进行尝试优化:首先就是限流,将请求拦截下来,不要对系统造成太大压力;其次使用各种缓存,对于不需要访问数据库的资源缓存起来,提高响应速度,减少数据库压力;然后使用分布式部署,使用集群替代单机;还有优化接口对SQL进行调优等等。

记一次Spring Cloud压力测试

标签:平台   最大的   ali   方向   span   hystrix   erro   一个   通过   

原文地址:https://www.cnblogs.com/lkd934/p/9532224.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!