10多倍的性能差距之dawdler-series对比springCloud性能测试过程

做一个简单的介绍(相知者，会意无需多言。陌路人，难入心万语间。)

dawdler-series

dawdler-series 是一站式分布式应用、微服务架构的解决方案,其特点简单、高效（启动、运行速度快）、安全、灵活、可扩展性强. 功能包含webmvc架构、高性能分布式session、动态网关、验证架构(前后台通用表达式)、web拦截器、web监听器、服务过滤器、服务生命周期监听器、熔断器、链路追踪、健康检测、统一配置中心、分布式事务、支持读写分离的事务管理器、分库、分表、注册中心、服务间认证授权、高效的编译型aop、常用插件(schedule、cache、mybatis、dao、elasticsearch、redis、rabbitmq)。

dawdler-boot

dawdler-boot使创建独立的、生产级的基于dawdler-series的应用程序变得更加容易,支持ide中main方法运行,也支持通过maven工具构建fastjar独立运行
直接嵌入dawdler-server、undertow（无需部署WAR文件和dawdler-server服务文件）
提供统一规范的依赖关系,以简化并规范您的依赖配置

 

1、测试目标

本次测试从  启动时间、打包大小和wrk相关指标来做对比

Latency	请求的平均延迟（从发送请求到收到响应的时间）
Req/Sec	每秒处理的请求数（吞吐量）
Requests/sec	整体每秒请求数（即 QPS）
Transfer/sec	每秒传输的数据量（响应体大小）

 

2、操作系统

3、jdk版本 

jdk1.8（dawdler-series也有支持LTS版本 jdk17 jdk21 为了方便演示采用jdk.18）

4、软件版本 

4.1、 dawdler-series

dawdler web容器版本 undertow-core-1.4.28.Final

4.2、spring-cloud

spring-boot版本 1.5.22.RELEASE(最后一个1x的版本)

spring-cloud版本 Dalston.RELEASE

spring-cloud web容器版本 undertow-core-1.4.27.Final

5、测试步骤

分别下载准备好的压测程序.

下载wrk 压测工具(自己找方法)

dawdler-series的程序 http://dawdler.club/dawdler-series-stress-testing.zip

spring-cloud的程序 http://dawdler.club/spring-cloud-stress-testing.zip

解压并以maven项目导入到开发工具中 推荐vscode、eclipse。为什么没有 idea？ 当然idea也可以 只是我不推荐用商业软件、或破解版。如果非要用建议用社区版。

5.1、dawdler-series压测步骤

安装consul（用于做注册中心）安装步骤很简单 参考官网 https://developer.hashicorp.com/consul/install  不建议设token因为测试 越简单越好 

安装完成consul之后 访问consul控制台 http://localhost:8500/

创建一个/consul配置项用于做注册中心

/consul的内容如下：

host: localhost
port: 8500

参考下图：

 

基于导入的dawdler-series-stress-testing项目启动用户的基础服务

基于上图可以看到 用户服务已启动 启动用时 253ms。

继续启动web端

 

基于上图可以看到 用户web服务已启动 启动用时 525ms. 注意端口号为:8085。

通过wrk进行压测：

wrk -t12 -c400 -d10 --latency http://localhost:8085/user/infoNoDB?id=1

执行两次的结果如下图：

 

压测期间服务端与web端的 cpu、内存使用情况如下图：

 

 

 

观察cpu整体使用率大概为65%左右。

 

5.2、spring-cloud压测步骤

基于导入的spring-cloud-stress-testing项目启动eureka注册中心 如下图:

 

继续启动用户的基础服务

 

启动完成时间2278ms。

 

继续启动用户web端

启动完成时间2157ms。

通过wrk进行压测：

wrk -t12 -c400 -d10 --latency http://localhost:8765/user/infoNoDB?id=1

执行两次的结果如下图：

 

压测期间服务端与web端的 cpu、内存使用情况如下图：

 

 

 

观察cpu整体使用率大概为92%左右。

springcloud的web端在进行压测过程中开始报错 错误如下：

 

6、综合对比

6.1 、启动速度对比

架构	web端	服务端
dawdler-series	525ms	253ms
spring-cloud	2157ms	2278ms

 

在实际项目中(很多服务的情况下) dawdler-series的启动大概在800ms内完成。spring-cloud 大概在15-20秒左右完成。

6.2 、打包大小对比

以下都是最小依赖包的情况。感兴趣的可以看具体项目依赖。

架构	web端	服务端
dawdler-series	14M	9.3M
spring-cloud	35M	35M

6.3、性能对比

第一次请求

架构	10秒内成功请求次数	每秒处理成功请求	每秒传输字节数	总共传输字节数
dawdler-series	3791349	378801.02	101.87MB	1.00GB
spring-cloud	253093	25243.08	7.23MB	72.53MB

 

spring-cloud已经出现失败请求了  如上图中的 Non-2xx or 3xx responses: 595

 

第二次请求

架构	10秒内成功请求次数	每秒处理成功请求	每秒传输字节数	总共传输字节数
dawdler-series	4004514	396506.95	106.64MB	1.05GB
spring-cloud	23013	2289.08	709.34KB	6.96MB

 

第二次spring-cloud继续出现 Non-2xx or 3xx responses: 1833

 

出现这个错误时spring-cloud web端会报错 Caused by: feign.RetryableException: 无法分配被请求的地址 (connect failed) executing POST http://user-service/user/selectByPrimaryKeyNoDB。

 

写在最后

spring、spring-boot、spring-cloud 框架简化了很多开发步骤、提高了开发效率、学习成本个人认为还是很高的。特别是遇到一些坑需要排查源码才能找到问题。如我之前的文章 *(致命的bug)https://my.oschina.net/u/3861980/blog/5080608  、https://my.oschina.net/u/3861980/blog/11048734、（致命的bug）https://my.oschina.net/u/3861980/blog/11046282。

dawdler-series是一整套微服务解决方案(当然也支持单体应用啦) 具体请参考 https://dawdler.club 。同样简化了开发步骤，提供代码生成器、文档生成器来提高开发效率 。如果零基础学习对比 那一定比spring-cloud要简单的多。

https://dawdler.club  里面的快速入门提供了 dawdler-boot的入门示例。各个组件的文档也相对全面。

 

最后我想说适合自己的就是最好的，阿里的朋友提醒过我 也许你开源出来会有些喷子。你要做好心理准备。我给他的回答是  如果是那种恶意喷 我完全不care，有能力他写一套我看看？当然喷得对的 我还是愿意去改进的....欢迎出于好心的“喷”。

dawdler.club所有产品采用apache-2.0开源协议。无论学习、个人、商用等全部永久开源免费。永远不会考虑商业化（别问为什么... 因为我不需要用钱....）。