WSO2 Micro Integrator 4.2.0使用ScriptMediator时吞吐量骤降问题

1. 吞吐量骤降的核心原因 #

• 脚本引擎重复编译/初始化开销：默认情况下ScriptMediator未开启脚本缓存，每次请求都会重新编译JS/Groovy脚本，带来大量CPU消耗。
• 上下文对象转换损耗：消息上下文在Java层与脚本引擎间传递时，需要完成对象转换、数据拷贝，这是性能瓶颈的主要来源之一。
• 解释执行的天然劣势：脚本为解释执行模式，而MI原生中介器都是预编译的Java字节码，执行效率差距可达一个数量级以上。
• 资源泄漏与GC压力：若脚本中存在未正确释放的临时对象、外部连接等资源，会引发频繁垃圾回收，拖慢整体吞吐量。

2. 低性能损耗的替代方案 #

• 优先使用原生中介器组合：绝大多数脚本实现的逻辑（如消息字段提取、条件判断、payload转换），都能通过PayloadFactory、Filter、Property、Enrich等原生中介器组合完成，性能与无脚本场景基本一致。
• 开发自定义Java中介器：若逻辑复杂无法用原生中介器覆盖，可编写继承AbstractMediator的自定义中介器，编译为Jar包放入MI的lib目录，性能最优。
• 优化ScriptMediator使用方式：
  • 开启脚本缓存：在ScriptMediator配置中添加cache="true"，或在deployment.toml中设置[mediators.script] cache_enabled = true，避免重复编译。
  • 精简脚本逻辑：仅处理必要字段，避免操作完整消息payload，减少数据拷贝。
  • 调整JS引擎参数：使用JavaScript时，添加JVM参数-Dnashorn.args=--optimistic-types=true开启Nashorn编译优化模式。

3. 已知用户案例与解决方法 #

• 社区中大量MI 4.x版本用户反馈过类似问题，常见解决方法包括：
  • 将Groovy脚本的JSON字段处理逻辑替换为Enrich+Property中介器组合，吞吐量从300左右回升至4200+。
  • 开启脚本缓存后，部分场景下吞吐量提升5-10倍。
  • 调整JVM参数（增大堆内存、启用G1GC），缓解脚本执行带来的GC压力，提升运行稳定性。

内容的提问来源于stack exchange，提问作者arjun s