WSO2 DAS对传入事件的性能不佳？

我们使用WSO2 DAS 3.1.0从WSO2 API管理器接收事件并发送到数据库

如果我们向DAS发送大约70-100个事件/秒，持续4-5小时，则性能会慢慢恶化，并开始“落后”。起初，我们怀疑将结果事件推送到数据库时出现问题（我们有一个事件接收器、一个执行计划（每秒汇总事件）和一个数据库发布者），但现在我们得出结论，这不是问题，数据库完全可以跟上负载

为了隔离我们针对的问题，例如，从传入事件接收器（在执行计划中进行任何处理之前）向文件中添加了一个事件发布服务器，我们可以看到，当DAS性能恶化几秒钟时，该发布服务器也没有输出；因此，问题在于处理传入事件（我们还在将事件推送到数据库之间添加了一个队列，以确保没有背压传播到传入事件的处理中）

然而，真正奇怪的是，当这种行为发生时（DAS中处理传入事件的性能恶化），除了重新启动整个服务器（然后它会在几个小时内毫无问题地重新开始工作），就没有办法摆脱它。即使我们停止向服务器发送事件几天，当我们开始向服务器发送1-2个事件时，处理所有事件之间也需要几秒钟的时间（因此直接“滞后”于传入事件）。在重新启动DAS之前，处理传入事件的性能似乎会以指数级的速度降低

---

如果有任何关于在何处进行更改以避免此行为发生的潜在线索（清除内部事件也没有任何影响），我们将非常高兴。

经过大量调试，我们终于找到了原因

在我们的Siddhi语句中，我们使用了带有动态更改时间戳的“GROUPBY”，结果证明，它的处理效率极低，如以下错误所述：

---

在修补了指定的类之后，问题消失了（但目前仍然存在一个bug，因为产品没有发布动态的“分组依据”信息，所以该产品没有OOM）。

经过大量调试，我们终于找到了原因

在我们的Siddhi语句中，我们使用了带有动态更改时间戳的“GROUPBY”，结果证明，它的处理效率极低，如以下错误所述：

---

在修补指定的类后，问题消失了（但目前仍然存在一个缺陷，产品未发布动态“分组依据”信息，导致OOM）。

在中之前报告过类似问题，并且正在修复。您可以尝试在中使用WSO2 update manager更新产品，并查看问题是否已修复在中之前报告过类似问题，并且正在修复。您可以尝试在中使用WSO2 update manager更新产品，并查看问题是否已修复