Cache
Retrieving notifications for the view modules could be expensive in a system with many hundreds of thousands of notifications, especially at Notifications Dashboard level, which cuts across all available courses. To help mitigate the burden of running this query, the Notification System includes a per-user, per-session cache:
- The cache stores the results of a notification query for a specific user, session, and context. This means that the system keeps separate caches for each user for each course that the user logs into to, and at the global, Notifications Dashboard level.
- The user is able to manually refresh the cache. The refresh action clears the cache of all contexts for a given session.
- The cache will not be updated by the arrival of new notifications. The user will have to refresh manually to see them or wait for cache timeout. See the table below for default timeout values.
- The cache will respond to manual notification deletions. So, if the user deletes a notification from a particular view, it will also be deleted from the cache in all contexts.
The cache is configured using properties in the bb-config.properties configuration file.
| Property | Key | Default Value |
|---|---|---|
| Max Number of Elements | bbconfig.cache.nautilusCache.elements | 500 seconds |
| Time to Live | bbconfig.cache.nautilusCache.timetolive | 600 seconds |
| Time to Idle | bbconfig.cache.nautilusCache.timetoidle | 600 seconds |
| Eternal | bbconfig.cache.nautilusCache.eternal | No |
If the performance associated with displaying modules proves to be an issue, administrators can tweak these settings to increase the longevity of the cached notifications. The trade off here is that the longer the cache, the more out of date the displayed notifications may be.
Cache settings have no effect on notification distribution.
Notifications sizing
The notification store can grow quite large. This section includes strategies to prevent that.
Disable notifications that are not needed
By default, the system ships with all notifications enabled, which means that every notification that can be created, will be created, for all supported events. Depending on the size of your institution and the ways in which courses are set up at the beginning of the semester, this could lead to very large table sizes and associated degradations in performance.
It is a good idea to turn off notifications that are not needed. To do so, go to both the Course Settings => Default Notification Settings, and Organization Settings => Default Notification Settings page and set these notifications to Always Off for all available distributors.
An alternative is to turn off certain notifications during busy periods. For example, turn off Content Item Available notifications while course templates are being completed as those will most likely be responsible for the bulk of the notification load during that period.
Reduce notification lifespan
Notifications are periodically deletes notifications that have been around for longer than a certain number of days. The default setting is 120 days, which is approximately the length of a semester. You can control the mortality of these notifications by updating the Notifications Cleanup interval. Lower this setting to have notifications removed from the system more quickly. To learn more, see Setting Notification Options.
Use this setting with caution. Deleted notifications cannot be retrieved or easily reissued.
Notifications background tasks
The Notification System depends on two tasks, both of which are defined in the bb-tasks.xml configuration file.
| Task Name | Internal (minutes) | Purpose |
|---|---|---|
| NotificationRemoveStaleDataTask | 5 | This task has various functions:
|
| DistributionSendNotificationTask | 60 | Send Unprocessed notifications to all registered distributors. |
NotificationRemoveStaleDataTask
The age of notifications when cleanup occurs can be set by administrators on the General Notification Settings page.
All Due notifications will be transformed into Overdue events when their due date has passed. These include: Assignment Due, Test Due, Gradable Item Due, and Survey Due.
The last function of this task, deleting stale recipient data, executes once per day. Every time the task wakes up, it checks whether its execution time has arrived. If it has, it runs. The execution time is specified by the nautilus.staleDataRemove.executionTime property in the nautilus_config.properties configuration file.
Task periodicity
Changing the periodicity of this task will have the following effects:
- Change how promptly Due notifications become Overdue notifications. In the default configuration, notifications will be transformed a maximum of five minutes after their due date has passed.
- Change how promptly reminders are sent out. In the default configuration, they are distributed a maximum of five minutes after the reminder time.
- Change how promptly the stale-data deletion task runs. In the default configuration, it runs within five minutes of the designated time.
Performance considerations
The notification cleanup portion of this task runs nightly at a time specified by the nautilus.staleDataRemove.executionTime property in the nautilus_config.properties configuration file. By default it is set to run once a day at 1:00 AM.
This query is extremely performance-intensive because it essentially scans the entire eud_item_recipient table looking for out-of-date notifications and deleting them.
If you find that this task is a significant drag on your system despite all of these precautions, there are a couple of things you can do:
- Change its execution time. Many institutions have other maintenance tasks that run at night, and if this task conflicts with them or conspires with them to bring your database server to its knees, you can have it run at a different time. To be clear: Blackboard very much recommends against running this during the day or at any period where you expect people to be using the system heavily.
- Take steps to reduce the size of the notification store. The fewer notifications that you have, the faster this query will run. For tips on how to do this, see Notifications Sizing.
DistributionSendNotificationTask
To ensure that this task does not run for an excessive period of time, it deals with only a limited number of notifications in any given execution. Administrators can configure this setting in the nautilus.distribution.notificationsPerDistribution property in the nautilus_config.properties configuration file. The default setting is 10,000.
The distribution tasks sends notifications to all registered distributors. For most institutions this means that it sends only to the email distributor. Expect performance to degrade somewhat whenever a new distributor is added to the mix.
Task periodicity
Changing the periodicity of this task will change how often the system sends notifications. In the default configuration, a notification will be distributed no later than one hour after it was introduced into the system. System administrators can set the period in which notifications get distributed in the Learn system by editing the tasks.xml file in the BB_HOME/config/ folder. The period value is found in blackboard.platform.nautilus.service.internal.DistributionSendNotificationTask.
The number of notifications distributed per invocation also affects when a notification will be sent. Administrators can configure this setting in the nautilus.distribution.notificationsPerDistribution in the nautilus_config.properties configuration file.
Performance considerations
This task runs fairly frequently, but it places a ceiling on the number of notifications that it processes in a single execution. This two-pronged approach to distribution allows the system to send notifications soon after they become available without bogging down the system when the notification load is particularly large, for example, at the beginning of the semester when new courses are just coming online.
If the distribution process is degrading performance, reduce the periodicity, effectively substituting performance for promptness. If distributions are taking too long, simply reduce the number of notifications handled per execution.
Alternatively, if you find that notifications are not arriving promptly enough, reduce the periodicity of this task and the number of notifications that it processes per execution.
Some recipients are removed in name only. That is, their associated records actually remain and are merely marked with a DELETED status.
