Odoo Changelog — 2025-03-06

Thursday, March 6, 2025

1 change · master

Improvements(1)

Enhancements to existing features

[IMP] web, *: render web client without waiting for menus

Enterprisemasterweb_enterprisesale_timesheet_enterpriseweb_cohortweb_gridHigh impact

The web client can now open using menus saved in the browser instead of waiting for the server to rebuild them every time. This improves startup speed, especially on large databases, while still refreshing menus when changes are detected.

Original PR description

Before this commit, the menus were cached inefficiently. In fact, the current
menu hash is computed in order to store it it in the session_info.
Unfortunately, to compute the hash, the entire menus have to be built (but only
the hash is stored in the session_info). The previously calculated hash is then
used to fetch the menus. This way, if the menus haven't changed, the request is
already cached in the browser.

This means that the first time a user accesses the web client, the menu is
calculated twice (once to calculate the hash, and once for the menus
themselves). The next time the user accesses the web client, if the menus
haven't changed, the menu is calculated once, to compute the hash. And twice if
the menus have changed.
Note that there is an ORM inter-request cache that is shared by multiple
methods, and various actions can invalidate this cache. On large databases this
can happen several times a minute, in which case cache hits are unlikely.
Note also that, the web client, waits for this process to finish before
rendering itself. For large databases, calculating the menus can take a long
time, and slows down the web client quite a bit. Note that, the menus available
to a particular user depend not only on the ir.ui.menu, but also on groups.
This makes it difficult to compute the hash differently than it's done now.

Now, each time the user accesses the web client, the menus are fetched. Only
the first access, the web client will wait for the menus to render itself. The
menus are stored in the browser's local storage. The next time the user
accesses the web client, the saved menus are used to render the web client.
When the menus are returned from the fetch, the web client will evaluate them,
and if they are different, the web client will update them.
This means that the first time a user accesses the web client, the menus are
calculated and waited for only once. The next time the user accesses the web
client, the calculation for the menus is not waited for, and the web client is
rendered with the stored menus, and only updated if necessary.

task-id 4479844

#performance#web client#menus#startup

Before this commit, the menus were cached inefficiently. In fact, the current menu hash is computed in order to store it it in the session_info. Unfortunately, to compute the hash, the entire menus have to be built (but only the hash is stored in the session_info). The previously calculated hash is then used to fetch the menus. This way, if the menus haven't changed, the request is already cached in the browser. This means that the first time a user accesses the web client, the menu is calculated twice (once to calculate the hash, and once for the menus themselves). The next time the user accesses the web client, if the menus haven't changed, the menu is calculated once, to compute the hash. And twice if the menus have changed. Note that there is an ORM inter-request cache that is shared by multiple methods, and various actions can invalidate this cache. On large databases this can happen several times a minute, in which case cache hits are unlikely. Note also that, the web client, waits for this process to finish before rendering itself. For large databases, calculating the menus can take a long time, and slows down the web client quite a bit. Note that, the menus available to a particular user depend not only on the ir.ui.menu, but also on groups. This makes it difficult to compute the hash differently than it's done now. Now, each time the user accesses the web client, the menus are fetched. Only the first access, the web client will wait for the menus to render itself. The menus are stored in the browser's local storage. The next time the user accesses the web client, the saved menus are used to render the web client. When the menus are returned from the fetch, the web client will evaluate them, and if they are different, the web client will update them. This means that the first time a user accesses the web client, the menus are calculated and waited for only once. The next time the user accesses the web client, the calculation for the menus is not waited for, and the web client is rendered with the stored menus, and only updated if necessary. task-id 4479844