Recurring Events - managing fetch performance

Event calendars & schedulers
1

Our schedule has seen good uptake in usage with our user base. Currently, we have around 4,000 events in our DB, with about 1/4 of those being recurring events.

The problem is that - at this point - I don’t know which of those recurring events (REs) will show as occurrences in the schedule time frame, and as a result I have to select all REs from the DB and send all of those to the client. This is OK for now, but as time goes on it is not sustainable - as the number of RE’s increases, the time to fetch those from the DB, process them for the client, and then send to the client will consume too much time.

There are 2 ways that this problem might be alleviated:

  1. Fetch all REs from the DB. Then, process them - on the server - using RRULE logic to determine which of those will show occurrences in the current schedule start/end span.

  2. Add procedural logic to the DB to execute RRULE logic, so that only REs with occurrences are returned with the DB fetch action.

I don’t know if either of these will result in time savings, nor by how much.

Anyway, I wanted to see if anyone (user or Mobiscroll) has had experience with this problem, and what - if anything - worked for you.

2

Hi Patrick,

In case most of your recurring events have start and end properties, you could save those fields in the database as well, for narrowing them down to a period of time on fetching.

3

Hi Gabi,

Thanks for the reply.

Yes, that is true, and that is something that I will probably do soon (I do save all those parameters in the DB). However, that is still just a subset of events that I can filter out that way.

I’ll probably end up fetching all records and executing server-side RRULE logic to filter events.

Thanks,

Patrick