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

scalability improvements #4299

Merged
merged 1 commit into from
May 31, 2024
Merged

scalability improvements #4299

merged 1 commit into from
May 31, 2024

Conversation

sbwalker
Copy link
Member

@sbwalker sbwalker commented May 31, 2024

This PR introduces scalability improvements related to memory consumption...

Due to the eager loading / caching approach which was used when loading the collection of modules for a site, it was identified that sites which contain thousands of module instances have the potential to consume a lot of memory on the server - which can also affect the user experience of the application.

The following optimizations have been introduced to improve scalability:

Server

  • removed the Modules collection from the Site model to reduce the size of Site objects
  • this reduces the memory footprint of Site objects which are cached on the server
  • it also reduces the serialization/deserialization of Site objects requested over HttpClient connections (WebAssembly, .NET MAUI)
  • Site objects were previously cached on a per user/site basis... they are now cached on a site basis
  • this reduces the number of Site objects cached on the server - reducing the memory footprint
  • the Modules collection on the PageState object is now populated on each navigation and only contains the module instances for the page requested (rather than all module instances in the site)
  • the App.razor component passes PageState as a serializable parameter to the client application. The reduction in size of the PageState object improves performance.

Client

  • the SiteRouter now populates the Modules collection on the PageState object on each navigation and it only contains the module instances for the page requested (rather than all module instances in the site).
  • since the PageState is a cascading parameter passed to downstream components, it reduces the amount of data which is passed
  • this is especially important when using mixed render modes, as when PageState is passed across a render mode boundary (ie. static to interactive) the data needs to be serialized/deserialized.
  • reducing the size of objects requiring serialization improves performance

This PR introduces a behavioral breaking change, as the PageState.Modules property no longer contains a list of all module instances in a site - it only contains a list of module instances for the current page.

@sbwalker sbwalker merged commit 80f545f into oqtane:dev May 31, 2024
@zyhfish
Copy link
Contributor

zyhfish commented Jun 1, 2024

Hi @sbwalker , thanks so much for fixing the performance issue, I submit PR #4301 to fix a minor issue of when adding a new page, please help to check, thx.

@sbwalker
Copy link
Member Author

sbwalker commented Jun 1, 2024

Thank @zyhfish - there are probably a few more changes required as a result of #4299 however I wanted to get the main changes merged first.

sbwalker added a commit to sbwalker/oqtane.framework that referenced this pull request Jun 3, 2024
sbwalker added a commit that referenced this pull request Jun 3, 2024
changes as a result of #4299 related to  PageState.Modules
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

Successfully merging this pull request may close these issues.

2 participants