logo
menu
难以置信的性能优势,来自myddd-vert.x的性能测试报告 2021-04-11
myddd

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

事实胜于雄辩 -- 中文版

缘起,与Vert.x的相遇

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

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

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

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

由于是遵循DDD领域驱动编码理念而实现的,于是把它命名为myddd-vertxmyddd-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-backend框架(基于Java及Spring Boot的领域驱动框架)写了一个一模一样的数据写入业务,表结构,API请求,响应都一模一样。这是为了对比测试。

因为:没有对比,就没有伤害

背景说明:

  1. 两个服务都部署在相同的服务器上,配置一模一样

  2. 数据库使用Docker安装,未进行任何配置上的优化,这个对两种模式都是一样的

  3. Java + Spring部署时做了一些优化:

    • 基于传统线程模式,将系统最大允许线程数设置的足够大

    • 使用数据库连接池配置,连接池数为1500 (事实上在连接池为50的时候,压力测试无法进行,一压就全是报错)

    • ·将日志级别调整为error,减少日志输出

数据写入性能测试对比

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

压测部署图

test_1.png

网关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%


test_data_1.png

模拟项目的性能测试(基于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%


test_data_2.png

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

网络请求性能测试数据

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

test_2.png

注:

为了真实有效的反馈网关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与平均响应时间都在稳定的范围内。

test_data.png

初步结论

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

test_data_3.png

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

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

相伴,未来的前行

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

myddd_vertx.png

当前阶段的框架的Sonar数据

sonar_data.png

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

附录

  1. 为什么我会选择Vertx与Kotlin

  2. TeahEmpower性能权威测试

公众号关注公众号微言码道
点击返回
@ 2021-2024 御剑(lingen.liu) 版权所有