Performance Issue: CPU Load

sdowswell
(@sdowswell)

2 weeks, 3 days ago
I’m writing to report a performance issue I’ve traced in My Calendar that’s causing serious CPU load on a client site (WordPress on SiteGround, ~77 events, one weekly recurring event ending in 5 weeks).

Symptom: With the plugin active, the homepage (which uses [my_calendar_upcoming]) takes 30-40 seconds to load. Disabling the plugin drops load time to under 1 second. This was severe enough that SiteGround suspended the site for excessive CPU usage.

Using Query Monitor, I found that for every event rendered, the plugin runs a nearly identical stack of ~15-20 separate queries, including:
- mc_get_first_event()
- mc_get_categories()
- mc_get_category()
- mc_get_location()
- mc_get_location_post()
- mc_check_category_relationships()
- Two separate WP_Term_Query calls (mc-location-access and mc-event-access taxonomies)
- update_meta_cache() / delete_metadata() for _occurrence_overlap
- mc_ts(), which runs SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP) fresh for every single event, even though this value is identical across all events in the same request
None of these individual queries are slow on their own (0.0001-0.0003s each), but the volume multiplies quickly – roughly 15-20 queries x 50+ events rendered = 750+ queries per page load. I’ve confirmed this isn’t a caching issue on my end: both Memcached (object cache) and SiteGround’s Dynamic Caching (full-page cache) are active, but since these are raw custom SQL queries against the My Calendar tables rather than calls wrapped in wp_cache_get()/wp_cache_set(), they bypass object caching entirely.

A few things that stood out as easy wins:
1. mc_ts() / the TIMEDIFF(NOW(), UTC_TIMESTAMP) calculation could be computed once per request and reused, rather than recalculated per event.
2. mc_get_categories(), mc_get_category(), and mc_get_location() all look like good candidates for wrapping in wp_cache_get()/wp_cache_set(), since the same categories and locations are being re-fetched repeatedly across events.
3. The repeated WP_Term_Query calls for access-control taxonomies per event also seem like they could be batched rather than run individually.
For my part, I’ve disabled the plugin on the effected website. Hoping this is a helpful report so the fix can be included on the next update.

Thanks

Stacey

Viewing 8 replies - 1 through 8 (of 8 total)

Plugin Author Joe Dolson
(@joedolson)

2 weeks ago

So, I’ve run significantly larger calendars than this on Siteground, and it doesn’t have anything like that kind of performance difficulty. mc_ts(), for example, is already cached as a transient, and shouldn’t query more than once a week.

Are you running the latest release of My Calendar?

Is 77 events the number being rendered in that one my_calendar_upcoming call, or is that the total number of events?

Thread Starter sdowswell
(@sdowswell)

2 weeks ago

The site is running the latest version of both WordPress and My Calendar and the call is only rendering 6 events or so out of the total 77.

The plugin is currently inactive on the site, but as soon as I reactivate it the cpu load and bandwidth both spike. Only way to keep from triggering another overage is to shut it down.
Plugin Author Joe Dolson
(@joedolson)

1 week, 6 days ago
Can you share the rest of your installed plugins? I’m wondering if there’s something interfering, because almost all of that should already be cached, and even if not, most of the queries shouldn’t be slow queries.

Looking at the specific items you mentioned:
- mc_get_first_event() is cached in a transient
- mc_get_categories() is only queried if it doesn’t already exist in the event object, and is cached in a transient.
- mc_get_category() is fetched as a static variable that falls back to a transient if needed.
- mc_get_location() is also fetched as a static variable falling back to a transient if needed.
- mc_get_location_post() is not cached, but it’s *caller*, mc_get_location() is.
- mc_check_category_relationships() should only be called in the admin, so I’m not sure why you’re seeing that at all.
*But* I see that you mention a call to _occurrenc_overlap, and that suggests a problem. That’s only queried on the front-end if an event has an invalid date structure – specifically, a recurring date structure that causes it to overlap on itself. E.g., a recurring event that repeats weekly, but has a start date and an end date that are more than a week apart. If that’s the case, you should be seeing a warning about invalid events in the admin.
Thread Starter sdowswell
(@sdowswell)

1 week, 6 days ago

There’s a lot of other plug ins in play, but they seem to be running fine until the My Calendar plugin is activated. There’s only one recurring event. There’s no error thrown. I have tried to adjust that event’s dates and saw no change in CPU load.

Thread Starter sdowswell
(@sdowswell)

1 week, 6 days ago

I should also mention: i keep seeing the error “Failed to initialize plugin: ips” on the plugin events pages. I’m not sure if this is related.

Plugin Author Joe Dolson
(@joedolson)

1 week, 3 days ago

That doesn’t mean anything to me regarding My Calendar; but the message generally means that a plugin failed to initialize; “ips” would refer to the plugin that failed to start.

There aren’t any plugins in the repository that use that slug, but it could be a must use plugin that is supposed to auto-initialize, possibly provided by the webhost. It could well be worth exploring what that is.

Thread Starter sdowswell
(@sdowswell)

1 week, 1 day ago

Following up on this, I methodically went through all the plugins on this website and found a conflict with the WP-Optimize – Clean, Compress, Cache plugin. I’m not sure what it is exactly, but having this and the My Calendar plugin activated at the same time triggered a CPU spike within seconds of being enabled together.

Plugin Author Joe Dolson
(@joedolson)

6 days ago

I’ll install that plugin and see what I can learn!

Viewing 8 replies - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.