Option to send and retrieve events (via cluster mechanism) without going to the database
GENERAL
TESTING
GENERAL
TESTING
Description
The events processing in Sakai currently polls the sakai_events table periodically to check for new events on other nodes in the cluster that should be processed. This works OK for smaller installations (up to 4 nodes) but as the number of nodes in the cluster increases the number of requests against the events table goes up linearly. This becomes a serious load on the database as the number of events in the table increases and the number of nodes in the cluster increases (past 10 for example).
There should be an optional way to send the events processing through a path which does not use the database so that events are only logged in the table but it is never polled by Sakai actively (except by stats processing - e.g. sitestats).
Ideally, we would also remove some of the indexes from the events table at some point to reduce the load created by inserting events but this can happen later.
The events processing in Sakai currently polls the sakai_events table periodically to check for new events on other nodes in the cluster that should be processed. This works OK for smaller installations (up to 4 nodes) but as the number of nodes in the cluster increases the number of requests against the events table goes up linearly. This becomes a serious load on the database as the number of events in the table increases and the number of nodes in the cluster increases (past 10 for example).
There should be an optional way to send the events processing through a path which does not use the database so that events are only logged in the table but it is never polled by Sakai actively (except by stats processing - e.g. sitestats).
Ideally, we would also remove some of the indexes from the events table at some point to reduce the load created by inserting events but this can happen later.