【问题标题】:DataWeave vs Java PerformanceDataWeave 与 Java 性能
【发布时间】:2020-10-03 18:04:32
【问题描述】:

我需要迭代近百万条记录。当前代码是用 Dataweave 编写的,带有过滤器和排序逻辑。但是,我看到了性能问题。我正在考虑使用 Java 组件将此 DataWeave 逻辑转换为 Java,并查看这是否会提高性能。

如何提高代码的性能?

【问题讨论】:

  • 您能发布您的 DW 代码吗?您需要什么级别的性能?是时间的问题,还是记忆的问题?在某些情况下,Java 更适合某项任务,而在其他情况下,DW 更适合。但是不看任何代码就不可能说出你的是什么。

标签: mule esb dataweave mule-esb


【解决方案1】:

如果您使用Global functions'p()' functions,Data weave 会出现一些性能问题。 如果您的 dwl 中有任何此类功能,请避免使用。

由于您正在处理大量记录,如果记录相同,您可以使用scatter-gather 模式并利用记录的异步处理。您可以通过配置执行转换/过滤逻辑的线程池来进一步调整性能。

关于分散聚集模式的实现,您可以参考link。 您在数据编织中实现的订单逻辑可以移动到自定义聚合器,您可以根据自定义逻辑重新排序记录

如果没有任何帮助,请考虑在您的自定义 Java 组件中使用 Java8 Streams API 来过滤和排序记录。

【讨论】:

    【解决方案2】:

    Dataweave 最擅长它的工作。您愿意通过您的应用程序处理多少记录并不重要。此外,主要约束不是数据编织,而是分配的 App 内存和 Vcor​​e。如果超过一百万,您必须考虑暂停处理记录。此外,您必须以合理的时间延迟定期分块/批量执行处理操作。

    根据我的测试,任何在 0.1Vvores 和 1 个工作器上运行的应用程序通常都会遇到 Mule Health Monitor,最终导致崩溃,如果连续跑了15个小时或更长时间。 一个好的经验法则是永远不要超过 70% 的系统资源使用或 CPU。

    注意:强烈建议不要将 Mule Java 组件用于复杂、重复、负载较高的执行。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2012-08-06
      • 1970-01-01
      • 2011-10-02
      • 2013-12-01
      • 2011-08-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多