难以置信的性能优势，来自myddd-vert.x的性能测试报告-低调大师

难以置信的性能优势，来自myddd-vert.x的性能测试报告

2021-06-23 552

“Talk is cheap. Show me the code.” -- 英文版

事实胜于雄辩 -- 中文版

缘起，与Vert.x的相遇

我曾经在1月底的时候因为一个随意的想法，去了解了下关于『响应式编程』的一些概念，并且无意间看到了Vert.x

当时只是花了2天不到的时间，把官方文档大致从头到尾阅读了下，从文档上就觉得这个玩意非常好。第一印象是：简洁高效，又足够优雅。

当时的想法也比较简单，看下能不能给自己在后端找到一种新的编程模式，因为这几年我的工作重心其实是在移动端及前端上，再返回后端对我来说，是仍然使用Java+Spring的传统编程风格，还是重新选择实现一套全新的模式，都是可选项。

所幸，由于这些年自己不断的在各种开发语言及框架中打转，早已不抗拒任何新技术并欢迎及愿意尝试更好的技术，于是便决定基于Kotlin+Vert.x写一套基础框架尝试下。

由于是遵循DDD领域驱动编码理念而实现的，于是把它命名为myddd-vertx，myddd-vertx的第一个版本在年前休假的的时间中可能2周不到就出来了。

这便是我与Vert.x的相遇。

我在1月写过一篇文章为什么我会选择Vertx与Kotlin讲述了自己当时选择它们的心路历程，末尾我会附上文章链接

相知，在实际项目中的应用

在2月初时就完成myddd-vertx的雏形，于是在年初给自己定的2021年的个人技术目标的几点中就包括这一点：

在实际的项目中验证并使用myddd-vertx

但我并没有意料到能在这么短的时间内能在公司的项目中用上myddd-vertx。对我而言，这真是一个绝佳的机会，因为这能够极快的验证与完善myddd-vertx

于是大约从3月初起，正式开始使用myddd-vertx来实现这个项目。我把它在这里称之为网关X

网关X的背景简述

我们公司有一套类似企业微信的产品WorkPlus，事实上我们的产品早于企业微信及钉钉等互联网产品，只是我们的知名度远不及上述公司。我们的产品主要是TO B。

企业微信与我们的产品类似，都有一套提供给第三方服务接入自己产品的API，举例来说：你可以基于我们的API或企业微信的API编写一个考勤的小应用。

但两者的API并不一致，项目X就是用来屏蔽两者API的差异，提供一套一致的API给小应用调用，以便开发一次，支持在不同的平台上运行。

所以，它有点网关的概念。这就是网关X

我是在3月初开始这个项目，3月底就其实已经编码结束，本周对这个完成编码的项目做性能测试，其结果确实有点超出我的预料之外。

虽然之前在国外知名的性能比拼网站TeahEmpower中看过它的数据，知道它很好，但真正自己编写一个项目再来跑一下性能测试，感觉还是完全不同的。有一种耳听为虚，眼见为实的感觉

题外话：关于性能测试这个事，我也有一些感触，因为感觉这个事首先在开发人员中不普遍，甚至我认定大多数公司可能从上到下都不太重视这个事情。所以我准备后续写篇文章: 性能测试这个事，谁的责任？

惊鸿一瞥，性能测试大比拼

网关X的项目的性能测试其实应该包括两个维度：

一个维度是对其本身数据读写，也就是数据库存储这一块做性能测试
另一个维度是对其的请求转发，类似网关性质的这个点做性能测试

这周，我对这两个维度都做了性能测试。

在对数据库写入做性能测试中，我使用了自己的myddd-java框架（基于Java及Spring Boot的领域驱动框架）写了一个一模一样的数据写入业务，表结构，API请求，响应都一模一样。这是为了对比测试。

因为：没有对比，就没有伤害

背景说明：

两个服务都部署在相同的服务器上，配置一模一样
数据库使用Docker安装，未进行任何配置上的优化，这个对两种模式都是一样的
Java + Spring部署时做了一些优化：
- 基于传统线程模式，将系统最大允许线程数设置的足够大
- 使用数据库连接池配置，连接池数为1500 （事实上在连接池为50的时候，压力测试无法进行，一压就全是报错）
- ·将日志级别调整为error，减少日志输出

数据写入性能测试对比

所有性能测试都是在Vultr云服务器上完成的。因为它的按使用时间计费比较方便，用完就销毁。

压测部署图

网关X性能数据 (基于Kotlin + Vert.x)

**并发数：200000 (20万) ** （以每秒发送2000个请求，不断循环的模式产生的总并发数）

TPS/秒： 4931.1/s

平均响应时间： 333ms

成功率： 100%

并发数：280000 (28万)

TPS/秒： 3926.6/s

平均响应时间： 466ms

成功率： 100%

**并发数：360000 (36万) **

TPS/秒： 4933.9/s

平均响应时间： 549ms

成功率： 100%

模拟项目的性能测试（基于Java + Spring Boot)

并发数：20000 (2万)* （以每秒发送2000个请求，不断循环的模式产生的总并发数）

TPS/秒： 593.6/s

平均响应时间： 1423ms

成功率： 100%

**并发数：30000 (3万) **

TPS/秒：634.0/s

平均响应时间：2091ms

成功率：100%

并发数：40000 (4万)

TPS/秒： 618.8/s

平均响应时间：2875ms

成功率： 100%

事实上，从压测数据上可以看出，两者的性能都不在同一个数量级上。压测Vert.x是从20万起步压测，而传统的Spring做不到，只能从2万起步。20万整个程序直接无响应。

网络请求性能测试数据

这个测试，只针对 myddd+vert.x模式做了测试，因为有了前面的测试，也没有必要再整个传统模式来对比了。（主要是懒，要时间）

注：为了真实有效的反馈网关X的性能，远程服务并未使用真实的企业微信或我们的产品等，而是MOCK了一个实现，在保障其性能足够高效的情况下以验证网关X项目的性能

性能数据 (基于Kotlin + Vert.x)

**并发数：120002 （12万） *** （以每秒发送2000个请求，不断循环的模式产生的总并发数）

TPS/秒： 3762

平均响应时间： 391

成功率： 100%

并发数：240002

TPS/秒： 4015

平均响应时间： 435

成功率： 100%

并发数：360002 （36万）

TPS/秒： 3994

平均响应时间：451

成功率： 100%

...

并发数：1200002 (120万)

TPS/秒： 4019

平均响应时间：484

成功率： 100%

省略了中间一些数据，因为大致差不多，性能测试的过程中并发数从小到大增加，但其TPS与平均响应时间都在稳定的范围内。

初步结论

当然，我的测试并一定全面，只是抽取了项目中的几个点来测试，但我认为基于自己的测试数据与TeahEmpower的权威测试结合来说，已经足以说明Vert.x强大的性能表现了。

相比传统的Java + Spring同步编程模式，Vert.x这种异步编程模式的性能优势是难以置信的。不要说传统TO B项目，就算是TO C互联网项目应对也绰绰有余。

当然，软件的世界没有银弹，凡事有利就有弊，你有没有做好迎接异步编程的挑战呢？

相伴，未来的前行

经过这个项目的实战，我的myddd-vert.x也增加及完善了挺多功能。也将孵化出第一个版本了。

当前阶段的框架的Sonar数据

我相信未来很长一段的时间内，我都将与其相伴。

附录

访问【微言码道】官网 https://taoofcode.cc - 用我们微小的力量传播编码之道

访问【myddd-全栈式领域驱动】官网: https://myddd.org

微信关注我们

原文链接：https://my.oschina.net/lingenliu/blog/5087024

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

🏆JVM技术专题-线上解决方案（2）网络问题分析和故障排查规划指南

系列目录 🏆JVM技术专题-线上解决方案（1） GC问题分析和故障排查规划指南 🏆JVM技术专题-线上解决方案（2）网络问题分析和故障排查规划指南 🏆JVM技术专题-线上解决方案（3）内存问题分析和故障排查规划指南前提概要涉及到网络层面的问题一般都比较复杂，场景多，定位难，成为了大多数开发的噩梦，应该是最复杂的了。这里会举一些例子，并从tcp层、应用层以及工具的使用等方面进行阐述。超时超时错误大部分处在应用层面，所以这块着重理解概念。超时大体可以分为连接超时和读写超时，某些使用连接池的客户端框架还会存在获取连接超时和空闲连接清理超时。读写超时 readTimeout/writeTimeout，叫做so_timeout或者socketTimeout，均指的是数据读写超时。注意这边的超时大部分是指逻辑上的超时。soa的超时指的也是读超时。读写超时一般都只针对客户端设置。连接超时。 connectionTimeout，客户端通常指与服务端建立连接的最大时间。服务端这边connectionTimeout就有些五花八门了，jetty中表示空闲连接清理时间，tomcat则表示...

2021-06-23

444

“ 本文我来分享下与我们（搞容器化/K8S 从业者）息息相关的一个基础项目 runc[1] 是如何自 2016 年发布了 v1.0.0-rc1 到现在历经 5 年长跑，从 rc1 一直到 rc95 ，如今终于正式发布 v1.0 版本的过程，及这中间的故事。 ” 大家好，我是张晋涛。在 2018 年 11 月底时，我写了一篇文章《runc 1.0-rc6 发布之际》[2] , 那应该是我第一次公开介绍 runc。如果你还不了解 runc 是什么，以及如何使用它，请参考我那篇文章。本文中不再对其概念和用法等进行说明。在 2019 年 3 月底时，我写了另一篇文章《runc 1.0-rc7 发布之际》[3]，介绍 runc 1.0-rc7 发布的原因，及那个版本中最主要的修复 CVE-2019-5736 。其中也介绍了关于 runc/Docker 等对于 Linux 内核兼容性的问题，感兴趣的小伙伴可以看看。关注我的朋友们，应该也在 K8S 生态周报[4] 中多次看到过我对 runc 的介绍，包括其特性及安全漏洞等方面。在 2015 年 6 月， Docker ，CoreOS 和...

2021-06-23

661

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。