您好,欢迎访问这里是深圳市硕远科技有限公司!
戴尔服务器价格_IBM联想配置_浪潮代理-深圳市硕远科技有限公司
联系我们
戴尔服务器价格_IBM联想配置_浪潮代理-深圳市硕远科技有限公司
邮箱:2324898850@qq.com
电话:400-080-6079
地址:深圳市龙华区河背工业区108创业园A301
当前位置:主页 > 新闻动态 > 行业新闻 >

行业新闻

spring赌上未来的一击:WebFlux性能实测
发布时间:2021-08-11 00:00浏览次数:

最近花了一点时间系统的测试验证了在SpringBoot框架下使用SpringMVC和Spring WebFlux两种框架开发接口,对比了响应时间以及压测吞吐量的区别。

spring赌上未来的一击:WebFlux性能实测

WebFlux&SpringMVC

如果对WebFlux还不了解的同学,那么你需要学习了解一下。官网地址:https://spring.io/

实践证明,使用WebFlux开发接口能够大幅提升接口的吞吐量

相关参数:

  • 测试机器:Linux CentOS6.5 4核16G
  • SpringBoot版本:2.2.2.RELEASE
  • JDK版本:jdk1.8.0_151

本文主要内容如下:

  1. 使用tomcat容器的代码演示
  2. 使用netty容器的代码演示
  3. apachebench(ab)压测接口,对比性能数据

文中代码较多,建议大家收藏后,有时间自己亲自动手开发并压测来验证结果。

tomcat容器下的代码演示

我们先基于tomcat容器来验证传统的SpringMVC以及基于Project Reactor两种方式开发接口的区别。

先来迅速搭建一个基于SpringBoot-2.2.2.RELEASE版本的demo项目,pom.xml核心依赖如下:

spring赌上未来的一击:WebFlux性能实测

SpringBoot父级依赖

spring赌上未来的一击:WebFlux性能实测

web依赖&project reactor依赖

项目启动类:

spring赌上未来的一击:WebFlux性能实测

再定义一个传统的service,为模拟真实环境请求,service下的方法请求耗时100ms:

spring赌上未来的一击:WebFlux性能实测

模拟耗时100ms

最后我们写三个接口,每个接口采用不同的方式:

  1. 使用自定义调度器的方式
  2. 使用缓存的弹性调度器
  3. 传统的SpringMVC方式

代码如下图所示:

spring赌上未来的一击:WebFlux性能实测

三种接口开发方式

ab压测

我们先对上面说的三个接口进行压测,为避免网络环境影响,我们直接在服务器上使用ab进行压力测试。

压测分三组,每组压测这三个接口,每个接口发起10w请求,每组用户数分别为200、500、1000,从而查看不同用户数请求下的响应结果。

第一组

压测结果:

spring赌上未来的一击:WebFlux性能实测

10w请求数 200用户

可以看见传统的SpringMVC方式已经有阻塞了,最长的一次请求1107ms,但是整体性能基本一致,因为200个线程刚好是tomcat的线程池最大默认数。

第二组

ab -n100000 -c500 http://127.0.0.1:8080/hello1?id=1ab -n100000 -c500 http://127.0.0.1:8080/hello2?id=1ab -n100000 -c500 http://127.0.0.1:8080/hello3?id=1

压测结果:

spring赌上未来的一击:WebFlux性能实测

10w请求 500用户

500用户请求时候可以看到hello3接口的响应时间已经是hello1和hello2两个接口响应时间的2倍以上了,但是基于project reactor响应编程开发方式的响应时间依旧和200用户一致。

我们继续将用户数加到1000。

第三组

ab -n100000 -c1000 http://127.0.0.1:8080/hello1?id=1ab -n100000 -c1000 http://127.0.0.1:8080/hello2?id=1ab -n100000 -c1000 http://127.0.0.1:8080/hello3?id=1

压测结果:

spring赌上未来的一击:WebFlux性能实测

10w请求 1000用户


我们发现基于project reactor开发的接口响应时间依旧坚挺,传统SpringMVC方式开发的接口90%响应时间已经高达500ms了。

spring赌上未来的一击:WebFlux性能实测

大家可以发现hello1和hello2两个接口的实现方式其实是一致的,无非是自己定义一个Scheduler还是用reactor默认的Scheduler,如果大家点进去看源码其实是一个意思,所以在性能上一致保持一致也是合理的,本质上都是无所不在的线程池:

spring赌上未来的一击:WebFlux性能实测

至此我们就完成了在tomcat容器下的两种不同方式的接口开发以及得到相应的性能压测数据。

netty容器下代码演示

将pom.xml中的spring-boot-starter-web依赖换为webflux依赖即可:

spring赌上未来的一击:WebFlux性能实测

webflux依赖

还是刚刚那三个接口,启动项目可以看到控制台有如下日志输出:

代表我们这是一个基于Netty的web服务。

这里我们直接压10w请求,1000用户:

ab -n100000 -c1000 http://127.0.0.1:8080/hello1?id=1ab -n100000 -c1000 http://127.0.0.1:8080/hello2?id=1ab -n100000 -c1000 http://127.0.0.1:8080/hello3?id=1

压测结果:

spring赌上未来的一击:WebFlux性能实测

netty下压测10w请求1000用户

再和tomcat下同一压测参数进行对比:

spring赌上未来的一击:WebFlux性能实测

tomcat下压测10w请求1000用户

是不是发现netty的性能比tomcat更加优越?99%的请求在149ms即可完成。如果大家自己实操的话也会发现吞吐量也会较tomcat有大幅度的提升。

总结

我们始终都在不遗余力的追求如何开发一个高并发、低延迟的接口

通过本文实操以及linux服务器下长时间的压测,可以验证的是我们可以使用WebFlux来替代SpringMVC,从而获取更好的性能,更高的并发。如果你还和我一样,对WebFlux还一知半解,那么从今天起开始学习起来吧。

感谢您的阅读,如果本文对你有所帮助,欢迎点赞、转发。关注“java架构设计”,免费阅读更多技术干货文章。

400-080-6079