Thanks Dave for taking the time to write this. Perhaps this can be incorporated into the notifications package docs.
Your timing is also interesting. In trying to track down certain performance problems with openacs.org, I found a pretty serious one relating to the notifications package.
There is a scheduled proc called "notification::sweep::sweep_notifications", which is run as often as every minute if you have any instantaneous notifications defined (ie, forums).
In particular, there is a very nasty query in "sweep_notifications" which causes the openacs.org server load to rise dramatically, free memory to drop from 450MB to under 10MB, and causes the postmaster process to become a huge CPU hog (60 to 90%)!!! Here it is:
select notification_id,
notif_subject,
notif_text,
notif_html,
user_id,
type_id,
delivery_method_id,
response_id
from notifications inner join notification_requests using
(type_id, object_id)
inner join acs_objects on (notification_requests.request_id =
acs_objects.object_id)
left outer join notification_user_map using (notification_id,
user_id)
where sent_date is null
and creation_date <= notif_date
and interval_id = '2889'
order by user_id, type_id;
Don has made some suggestions and I will look into it further. But I thought folks should be informed in case anyone else is experiencing performance problems with their servers.
