推动 Mendix 性能限制 | Mendix

跳到主要内容

推动 Mendix 性能限制

推动 Mendix 性能限制图像

作为低代码平台, Mendix 旨在适用于各种规模范围内的所有类型的业务。这是我们采用基于节点的部署的原因之一。它允许您选择最佳级别的处理能力来支持您的应用程序 - 不会太多,也不会太少,而是恰到好处。

这可让您平衡性能与成本。这也意味着您可以从小处着手,然后随着用户数量的增加开始扩大应用程序的规模。

但是,如果你的应用程序真的开始流行起来,会发生什么?如果你的用户群猛增,你需要处理的交易数量成倍增加,那么 Mendix 管理它?

高使用率应用程序 Mendix;100 万并发用户

挑战已开始!

在这里 Mendix,我们喜欢将平台推向极限。我们喜欢不断将事物做得更大、更好、更大胆,直到最终突破。毕竟,突破是测试的最佳方式。为了追求这一历史悠久的消遣,我们问自己:“我们可以支持多少个并发用户?一千?一万?十万呢?”我们回答说:“让我们找出答案!”

我们知道什么?

我们的客户遍布全球,在 Mendix 平台。有些是为少数用户运行的小型应用程序,而有些则是为大量用户运行的真正的企业级应用程序。

例如,PostNL 每天通过其订单管理系统处理超过一百万份订单,迪拜市政府每月的页面浏览量超过一百五十万次。因此我们知道 Mendix 应用程序可以处理繁重的工作负载。问题是,我们到底能承受多大的负载?

我们的测试是什么样的?

在这种情况下,单个测试是用户完成多笔交易。我们的目标是让十万名用户同时完成交易。

首先,让我们定义一个事务。什么是已完成的事务?我们正在寻找已完成的数据库提交操作——向数据库添加新数据的操作。它可能是一条全新的记录,也可能是对现有记录的更改。关键是数据库中的数据被该操作永久更改。

Mendix 是一个巨大的平台,在构建应用程序时提供许多不同的可能性。这为我们在选择如何应对这一挑战提供了大量的选择。为了使其与实际业务情况保持一致,我们选择了一项相对简单的任务:费用报销。

基本原则是用户登录系统并发送一系列简单的费用报销单。我们选择此时省略文件上传,这样数据量就不会成为限制因素。我们只想使用基本的插入和更新事务进行评估。

我们如何建立我们的 Mendix 性能极限测试

应用程序实现

对于我们的测试应用程序,我们从一个基本模板开始,并添加了一些非常简单的表单和功能来创建一个费用应用程序。前端保持在最低限度,没有花任何精力去优化任何图像、CSS 或脚本。我们的注意力主要集中在创建幕后逻辑以支持我们的测试。

推动 Mendix 绩效限制_费用提交微流程

测试工具

为了执行这些测试,我们使用了公司其他部门已经使用过的工具:Gatling。该工具旨在使用脚本加载测试平台。考虑到我们已经创建了一些脚本,并且拥有更改脚本所需的经验,这似乎是一个明智的选择。这使我们能够创建一个测试脚本,以我们所需的规模执行上述任务,从而实现我们想要的目标。

基础设施起点

要么大干一场,要么回家,对吧?我们考虑的第一件事是请求我们的支持团队可以提供的最大自定义节点。然而,我们无法实现日志记录级别,也无法拥有进行此测试所需的控制级别。我们的 Mendix Cloud 旨在为您处理日志和指标,并且易于管理和部署。它不旨在让您能够添加定制跟踪并摆弄配置,因此我们需要一个具有更多手动控制的环境,以便突破界限并打破常规!

因此,我们在 AWS EC2 上设置了第一个私有实例,并使用 Grafana 和 InfluxDB 添加了一些自定义分析和指标收集,以跟踪系统的性能。我们还安装了异步分析器和 YourKit,以直接更详细地观察运行时。为了保持简单并允许我们轻松更改,我们使用单个节点来托管应用程序和数据库。

执行性能极限测试

首次运行结果

当我们在此服务器设置上执行首次测试时,我们成功实现了可观的 5000 个并发用户。这是一个好的开始,但这并不是我们想要的。然后,我们开始迭代我们的服务器设置,以尝试尽可能地提高性能。

推动 Mendix 性能限制_性能图表

迭代和改进

第一个变化是增加 AWS EC 2 实例的大小(我们将大小增加了一倍),并对 Java 设置和数据库池进行了一些更改。这使我们的并发用户数达到 7000,每秒费用为 180。

接下来,我们将数据库与主实例分离,并将其完全放在单独的节点上。我们还与内部特种作战团队合作,扩大了我们的设置规模。这导致我们再次增加了交易数量。现在,我们实现了 15,000 个并发用户,吞吐量为每秒 373 笔费用。

在这些测试过程中,我们还注意到 Gatling 中的测试脚本存在差异。因此,我们对有效负载进行了更改,使其更接近 MxClient 提交的信息,并对提交的值进行了更改,使其更符合预期值。

我们实现的下一个重大飞跃是扩展我们的实例。我们切换到水平扩展的架构,在一个数据库服务器前面使用三个应用服务器。这种设置使我们能够以每秒 30,000 多笔交易的速度达到 700 个并发用户,但我们也注意到一个常见的网络瓶颈阻止了 Gatling 增加负载。

为了解决网络瓶颈问题并让 Gatling 提供更多负载,我们转而使用大量较小的 Gatling 实例。我们首先重新利用我们的一个应用程序节点并创建了以下设置。

推动 Mendix 性能限制_改进应用程序节点设置

这些变化使我们成功稳定地支持 25,000 名并发用户!正如您所预料的,由于拥有三台应用服务器,总数略有下降,但这是我们可以扩展以达到目标的设置。

为了完成最后的冲刺,我们做到了这一点。我们扩展了设置,以轻松支持四倍的处理能力提升,最终形成了一个拥有四个大型应用节点和一个两倍大的数据库服务器的集群。这似乎很多,但一家希望处理我们期望实现的并发用户数量的公司需要这种规模的基础设施。

推动 Mendix 性能限制_扩展应用程序节点设置

一旦我们有了四台应用服务器,我们就能够吸引到神奇的 100 万名客户!

外卖

我们已经证明的是 Mendix 平台和运行时,因此 Mendix 应用程序完全有能力处理如此多的并发用户。我们从这次练习中获得的有关配置和部署服务器的见解已与我们的云团队分享,我们将寻求改进我们的云基础设施。希望我们能够帮助提高已经很好的基础性能水平 Mendix 节点能够。

推动 Mendix 性能限制_构建和用户图表

下次将会更深入地介绍我们创建的设置以及为实现这一非凡结果而进行的更改。

推动 Mendix 性能限制_总是用蛋糕来庆祝

选择你的语言