I cracked open a debugger anyways and determined that the code to add a recurring event is the culprit.  Essentially it does a really slow while loop.  This loop can take 5-10 seconds per event.  If you have 10-20 recurring events, the performance gets horrible fast.  This has made me stop using the events module entirely.

In the existing Events module recurrence is one of many features and the assumption is that most Events are not recurring. This is not a criticism of the Events module, it is a fantastic module that works great for most people.

Like you I was having problems. I needed a DNN appointment calendar that could handle 1000's of recurring appointments.

The cause for the performance problems is that the Events module guesses on what records to grab. But not only can the guesses miss valid events, it has to work extra hard to weed out all the wrong guesses.

For example: The list view always processes more than a years worth of events to show the next few Events. It doesn't know in advance what Events might reoccur so it retrieves all Events for the next year. In a busy calendar thousands of records are retrieved then each one is checked for recurrence. Unfortunately if your recurring Event starts before the listing date it is very possible that it will be completely missed and not shown.

I ended up doing total rewrite of recurrence and the way Events are stored and retrieved.

Here is a post I wrote last year describing the changes.

---------------------------------------------------

I have a classic ASP intranet that has been in operation and evolving over the last 7 years. The calendar application sees heavy usage and contains hundreds of thousands of records.

I mentioned recurring events in a previous post so let me start there. Originally I stored recurring events as single record as I believe the DNN Events module does. Even though it may seem counter-intuitive I increased performance by splitting and storing the recurring record as many single events. Here's why.

The event is entered once but viewed hundreds of times. The idea is to optimize the data for viewing at the expense of storing more data (more about data structure later). With a single recurring record you have to cast a wide net to make sure have all the data. To view a date the required statement "SELECT * FROM Events WHERE @EventDate BETWEEN EventDateBegin AND EventDateEnd" will return lots of unnecessary records. In addition the recurring records will need to be evaluated to see if they fall on that date.

If you split recurring events at the time of entry to view a date the statement becomes "SELECT * FROM Events WHERE @EventDate = EventDate". It grabs exactly records needed with no recurring evaluation needed.

I have used two different data structures for storing the split recurring events.
In the first one the Events table remains as is and a second "EventDates" table is added containing:

ModuleID
EventID
EventDate

If a recurring event occurs over ten days then ten entries are made into this table one for each day. Normal non-recurring event dates are also added into this table. All date searches are then done against this table.

My users were not happy with the above method because all recurring events were still tied to a single record. If you change one you change them all.  For example if they had a recurring record that states there will be a meeting the first Tuesday of every month for the next two years. They wanted to change JUST next months event to say "Cancelled". 

I accomplished this by adding a ParentEventID field to my Events table. When editing a recurring event a check box would ask them if they wanted to change just this date. If checked a new (non-recurring) event would be created and the original recurring EventID would be put in the ParentEventID field. Any changes to the original recurring event can now be propagated to the new event via the ParentEventID field.

For example: "DELETE FROM Events WHERE EventID = @EventID OR ParentEventID = @EventID"