You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ones of the problems that we currently have is our bootstrap. Currently in mule it takes up to 2 to 3 seconds to bootstrap DW service and this is because it pre populates a cache to parse the most used DW modules. This is being done in order to avoid first request to pay for this very common modules to be parsed. Same complain was maid by the APEX team where the amount of memory and time consumed by this request is too big. In the APEX case is even worst as there is no shared cache so this toll is being paid every time.
Proposal
This proposal is not about bytecode generation and doesn't takle execution performance but rather trying to optimize bootstrap and be less memory demanding.
The proposal is to generate a binary asset out of a data weave file that will contain all the information necesary to generate a compiled module and that allows us to validate a mapping or a module against it.
What this means is that we need to generate a binary format of our modules that contains the ast information in a more compacted way plus additional information such as visibility and variable slots so that no compilation phase is required.
This will not only introduce a performance improvement in terms of CPU but also in memory consumption.
The text was updated successfully, but these errors were encountered:
We did an analysis from Mule Runtime side of the time taken to start a Runtime with a simple application (http:listener + logger), and by removing the modules loading the time went down from 10 secs to 8 secs (20% improvement). I don't expect only this solution to reach that number, but this along with other improvements to be on that neighborhood.
if the problem is bootstrap in Mule, why not initializing the service without any modules and then spawn a thread to load them while Mule is still initializing and deploying apps?
Because if we do that then the penalty goes to the first request where for example in cases of the mule gateway with 0.1 vcores was giving timeout. That is why for me is not moving the time to other fase but rather try to eliminate it
Compile
Problem
Ones of the problems that we currently have is our bootstrap. Currently in mule it takes up to 2 to 3 seconds to bootstrap DW service and this is because it pre populates a cache to parse the most used DW modules. This is being done in order to avoid first request to pay for this very common modules to be parsed. Same complain was maid by the APEX team where the amount of memory and time consumed by this request is too big. In the APEX case is even worst as there is no shared cache so this toll is being paid every time.
Proposal
This proposal is not about bytecode generation and doesn't takle execution performance but rather trying to optimize bootstrap and be less memory demanding.
The proposal is to generate a binary asset out of a data weave file that will contain all the information necesary to generate a compiled module and that allows us to validate a mapping or a module against it.
What this means is that we need to generate a binary format of our modules that contains the ast information in a more compacted way plus additional information such as visibility and variable slots so that no compilation phase is required.
This will not only introduce a performance improvement in terms of CPU but also in memory consumption.
The text was updated successfully, but these errors were encountered: