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开源协议。无论学习、个人、商用等全部永久开源免费。永远不会考虑商业化（别问为什么... 因为我不需要用钱....）。
