Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bootstrap / Compilation #48

Open
machaval opened this issue Jan 10, 2023 · 3 comments
Open

Bootstrap / Compilation #48

machaval opened this issue Jan 10, 2023 · 3 comments

Comments

@machaval
Copy link
Contributor

machaval commented Jan 10, 2023

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.

@elrodro83
Copy link

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.

Ref: https://docs.google.com/document/d/1t7nL1gA0id6258ru7vYGioatvf69iAphzScOP3ucByg/edit#heading=h.1scn2kj0khnh

@marianogonzalez
Copy link

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?

@machaval
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants