キャッシュ

ビューモジュールに通知を取得することは、特に利用可能なすべてのコースを縦断する通知ダッシュボードレベルに大量の通知があるシステムのコストを押し上げることがあります。このクエリの実行負荷を緩和するため、通知システムにはユーザごと、セッションごとのキャッシュがあります。

  • キャッシュには、特定のユーザ、セッション、コンテキストの通知クエリの結果が格納されます。つまり、システムはユーザがログインする各コースのユーザごとに個別のキャッシュをグローバルな通知ダッシュボードレベルで格納します。
  • ユーザはキャッシュを手動更新できます。更新アクションにより、一定セッションのすべてのコンテキストのキャッシュは消去されます。
  • キャッシュは、新しい通知ができても更新されません。ユーザは手動で通知を更新するか、キャッシュがタイムアウトになるのを待ちます。デフォルトのタイムアウトの値は下の表を参照してください。
  • キャッシュは手動の通知削除に応答します。このため、ユーザが特定のビューから通知を削除すると、この通知はすべてのコンテキストのキャッシュからも削除されます。

キャッシュは、bb-config.properties設定ファイルのプロパティにより設定されます。

キャッシュのプロパティ
プロパティ キー デフォルト値
要素の最大数 bbconfig.cache.nautilusCache.elements 500 秒
寿命 bbconfig.cache.nautilusCache.timetolive 600 秒
アイドル時間 bbconfig.cache.nautilusCache.timetoidle 600 秒
永続 bbconfig.cache.nautilusCache.eternal いいえ

表示されるモジュールと関連付けられたパフォーマンスが問題となる場合、管理者はこの設定に調整を加えてキャッシュされた通知の寿命を延ばすことができます。しかしその代償として、キャッシュの寿命が長くなればなるほど、古い通知がより多く表示されるかもしれません。

キャッシュ設定は、通知の配信に影響を及ぼしません。


通知のサイズ変更

通知ストアは非常に大きくなる可能性があります。このセクションでは、これを防ぐ方法を紹介します。

不要な通知の無効化

デフォルトでは、出荷時のシステムはすべての通知が有効な状態になっています。つまり、作成可能なすべての通知は、サポートされるすべてのイベントに作成されます。教育機関の規模と学期初めにコースがどのように設定されるかによって、これは非常に大きなテーブルとなり、パフォーマンスの低下を招く可能性が生じます。

不要な通知はオフにすることを推奨します。通知をオフにするには、[コース設定] => [通知初期設定]、[コミュニティ設定] => [通知の初期設定]ページに進み、使用可能なディストリビュータに対してこの通知を[常にオフ]に設定します。

また、ビジー状態のときに特定の通知をオフにする方法もあります。たとえば、コーステンプレートはその期間中通知ロードの大部分を実行する可能性が非常に高いので、これを完了する際にコンテンツ項目が利用可能の通知をオフにします。

通知期間の短縮

特定の日数を経過した通知は定期的に削除されます。この期間はデフォルトの設定では、120日間で大体1学期間となります。通知クリーンアップの間隔を更新することで、この通知の永続性を制御できます。通知をシステムからより迅速に削除するには、この値を低く設定します。詳細については、「通知オプションの設定」を参照してください。

この設定は注意して使用してください。削除された通知は復元できません。また、簡単に再発行することもできません。


通知のバックグラウンドタスク

通知システムは、いずれもbb-tasks.xml設定ファイルで定義される2つのタスクに依存します。

通知のバックグラウンドタスク
タスク名 内部(分) 目的
NotificationRemoveStaleDataTask 5 このタスクにはさまざまな機能があります。
  • 期限イベントにリマインダを送信する。リマインダは項目の期限のx日前に送信されます。xはユーザ個人の通知設定で設定できる数値です。
  • 期限が過ぎた期限通知を期限切れ通知にする。
  • ダイジェストのEメールを予定した時間に送信する。ダイジェストのEメールは管理者が設定した時刻に一日1回送信されます。
  • 古い受信者のデータを削除する。ここでいう古い受信者とは、システムにx日間保持された受信者の記録を指します。xは管理者が設定する数値です。デフォルトの設定では、受信者は1学期間保持されます。この操作は、一日1回のみ実行するよう設定されています。
DistributionSendNotificationTask 60 未処理の通知をすべての登録済みディストリビュータに送信する。

NotificationRemoveStaleDataTask

クリーンアップの実行が通知される間隔は、管理者が[一般的な通知設定]ページで設定できます。

すべての期限通知は、その期限が過ぎると期限切れのイベントに変更されます。これには課題の期日テストの期日採点可能な項目の期日、およびアンケートの期日などがあります。

このタスクの最後の機能である古い受信者のデータ削除は、一日1回実行されます。タスクが立ち上げられるたびに、実行時間になったかどうかを確認します。実行時間がくると、このタスクは実行されます。実行時間は、nautilus_config.properties設定ファイルのnautilus.staleDataRemove.executionTimeプロパティで指定します。

タスクの周期性

このタスクの周期性を変更すると、次の効果があります。

  1. 期限通知が期限切れ通知に変わるスピードを変更する。デフォルトの設定では、通知は期日が過ぎてから5分以内に変更されます。
  2. リマインダが送信されるスピードを変更する。デフォルトの設定では、リマインダ時間の5分以内に配信されます。
  3. 古いデータの削除タスクを実行するスピードを変更する。デフォルトの設定では、指定した時間の5分以内に実行されます。

パフォーマンスの検討事項

このタスクにおける通知のクリーンアップは、nautilus_config.properties設定ファイルのnautilus.staleDataRemove.executionTimeプロパティで指定された時間に毎晩一度実行されます。デフォルトでは、一日1回午前1時に実行するように設定されています。

このクエリは、実用上entire eud_item_recipientテーブル全体をスキャンして古くなった通知を検索して削除するため、極めて性能への依存性が高いものになっています。

十分な注意したにもかかわらずこのタスクがシステムで延々と行われている場合、次の手順を実行してください。

  1. 実行時間を変更する。教育機関の多くには夜間に行うその他のメンテナンスタスクがあります。このタスクがこうした他のタスクと競合したりデータベースサーバを従属させる場合には、別の時間に実行することができます。わかりやすくいうと、Blackboardは日中あるいはシステムにアクセスするユーザ数が非常に多い時間帯に、このタスクを実行しないことをお勧めします。
  2. 通知ストアのサイズを縮小する手順を実行する。配信する通知が少なければ少ないほど、このクエリは速く実行されます。この実行方法については、「通知のサイズ変更」を参照してください。

DistributionSendNotificationTask

このタスクが長時間にわたって実行されることを防ぐため、1回の実行では限られた数の通知のみを処理します。管理者はnautilus_config.properties設定ファイルのnautilus.distribution.notificationsPerDistributionプロパティでこれを設定することができます。初期設定は、10,000です。

配信タスクは、すべての登録ディストリビュータに通知を送信します。ほとんどの教育機関にとって、これはEメールディストリビュータのみに送信することを意味します。新しいディストリビュータがミックスに追加されると必ず何らかのパフォーマンスの低下があると考えてください。

タスクの周期性

このタスクの周期性を変更すると、システムが通知を送信する頻度が変更されます。初期設定では、通知はシステムに導入されてから1時間以内に配信されます。システム管理者は、BB_HOME/config/フォルダのtasks.xmlファイルを編集することで、Learnシステムで通知が配布される間隔を設定できます。期間の値はblackboard.platform.nautilus.service.internal.DistributionSendNotificationTaskにあります。

1回の呼び出しで配信される通知の数は、通知の送信時にも影響します。管理者はnautilus_config.properties設定ファイルのnautilus.distribution.notificationsPerDistributionでこれを設定することができます。

パフォーマンスの検討事項

このタスクは非常に頻繁に実行されますが、1回の実行で処理する通知数の上限を設定します。配信に対するこの二面的なアプローチにより、新しいコースがオンラインでアクセスできるようになったばかりの学期初めなど、通知ロードが非常に多い際でもシステムはダウンすることなく通知が利用可能になるとすぐに配信することができます。

配信プロセスがパフォーマンスの低下を招いている場合は、周期性を低くしてパフォーマンスの迅速性で効果的に代替します。配信が長くかかりすぎる場合は、1回の実行で処理する通知の数を減らします。

あるいは、通知が迅速に配信されない場合、このタスクの周期性と1回の実行で処理する通知の数を低くします。

一部の受信者は名前のみ削除されます。つまり、関連する記録は実際には保存されますが、[削除]のステータスのマークが付けられます。