Today I have been investigating a myriad of requests to the table, since it looks like SQL being bombarded with queries to EventInbox table.
This table stores actual alerts. In existing implementations nobody bothers to clean up the old alerts. Moreover, the deleted alerts physically stay in the table and are merely marked as "deleted".
The table has caching setup and will hit troubles as soon as it is bigger than AX's 2009 cache of 2000 records. Every time the user starts a client and the homepage is displayed, the client fires at least 18 SQL queries (tested on a cold cache) that do multiple selects to display the list of alerts in the Work List web part. In case there are more then 10 alerts, it also builds the list of "pages" for navigation between the alerts.
The SQL queries traverse through all existing alert records for the user for the company. So if the job has not been launched, there will be gradual decrease in performance stipulated by the volume of the data and the fact that the cache of 2000 records will have to be refreshed approximately every 100-150 alerts, which also is possible within the same loop.
So to help your users see the appreciable boost in load times, try to keep the EventInbox under 2000 records. To do this run Administration > Periodic > Notifications cleanup with the parameters, suggested by Czesława.
This table stores actual alerts. In existing implementations nobody bothers to clean up the old alerts. Moreover, the deleted alerts physically stay in the table and are merely marked as "deleted".
The table has caching setup and will hit troubles as soon as it is bigger than AX's 2009 cache of 2000 records. Every time the user starts a client and the homepage is displayed, the client fires at least 18 SQL queries (tested on a cold cache) that do multiple selects to display the list of alerts in the Work List web part. In case there are more then 10 alerts, it also builds the list of "pages" for navigation between the alerts.
The SQL queries traverse through all existing alert records for the user for the company. So if the job has not been launched, there will be gradual decrease in performance stipulated by the volume of the data and the fact that the cache of 2000 records will have to be refreshed approximately every 100-150 alerts, which also is possible within the same loop.
So to help your users see the appreciable boost in load times, try to keep the EventInbox under 2000 records. To do this run Administration > Periodic > Notifications cleanup with the parameters, suggested by Czesława.