When first released, Mule 4 introduced a brand new reactive execution engine and threading models. Benefits include high scalability, back pressure capabilities, and auto-tuning.
As part of Mule 4.3, we reiterated on these and made further improvements. More specifically, the three thread pools were combined into a single thread pool. Before jumping into the details, let’s quickly summarize how the threading models were set up prior to this release.
Sometimes (more often than we think), less concurrency is actually more. Not too long ago, I found myself in a conversation in which we were discussing non-blocking architectures, tuning, and performance. We were discussing that tuning for those models often starts with “2 threads per core” (2TPC). The discussion made me curious about how Mule’s batch module would perform if tested by 2TPC. I knew beforehand that 2TPC wouldn’t be so impressive on batch, mainly because it doesn’t use a non-blocking threading model.
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.