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

[Enhancement]: Upgrade to Azurite >= 3.28.0 and support in-memory persistence #1056

Closed
Xzelsius opened this issue Nov 29, 2023 · 3 comments · Fixed by #1063
Closed

[Enhancement]: Upgrade to Azurite >= 3.28.0 and support in-memory persistence #1056

Xzelsius opened this issue Nov 29, 2023 · 3 comments · Fixed by #1063
Labels
enhancement New feature or request

Comments

@Xzelsius
Copy link
Contributor

Problem

The current usage pattern of Azurite assumes that the caller is interested in persisting stored data beyond the lifetime of the node process. This certainly is useful for extended testing scenarios or where Azurite is actually used for production-like scenarios (perhaps a best-effort approach of free, on-prem Azure Storage). However, some Azurite use cases are more ephemeral in nature. For example, if you simply want to use Azurite for a single test run in a CI pipeline, you don't need the storage to persist beyond the lifetime of the node process.

Quote from: https://github.com/Azure/Azurite/blob/105a9cd217b881922016edb7a683ebea1ab3b28a/docs/designs/2023-10-in-memory-persistence.md

Depending on the amount and size of for example a blob there is an additional overhead on the test environment when Azurite has to write it to disk. In most scenarios, test containers won't survive more than one test run. So the overhead of writing to disk could be removed.

Solution

Upgrade to Azurite 3.28.0 or later and add support for the --inMemoryPersistence argument

Benefit

Using in-memory persistence may have a positive effect on overall performance of Azurite during tests, as it does not need to store stuff on disk.

Alternatives

Leave the current implementation as is

Would you like to help contributing this enhancement?

Yes

@Xzelsius Xzelsius added the enhancement New feature or request label Nov 29, 2023
@Xzelsius
Copy link
Contributor Author

If this is being added, --extentMemoryLimit <size limit in MB> should also be supported.
And it should be discussed whether in-memory persistence is the default or opt-in.

@HofmeisterAn
Copy link
Collaborator

Indeed, this sounds like a good and reasonable change to the module. Removing an existing default configuration is always a bit tricky with the current builder design (read-only configuration). This speaks for an opt-in approach (in addition, it reduces the chances of breaking existing configurations). Besides that, I do not really have an option regarding opt-in or opt-out.

@Xzelsius
Copy link
Contributor Author

So I would give it a try later today.
If I struggle to extend the current implementation I get back to you :)

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

Successfully merging a pull request may close this issue.

2 participants