Brook on "[Plugin: The Events Calendar] Events Calendar causes high MySQL/CPU load"

Howdy Cay,

Thanks for reaching out about this. We have a couple folks who have a passion for performance on our team, and I am definitely one of them. I'll do my best to answer your questions one-by-one.

We've been doing some digging. Using the P3 plugin, we scanned the site at random intervals, at different times of day, to evaluate resource usage of plugins.
The Events Calendar (free version) consistently uses more resources than all the other plugins combined(20 - this includes some resource hogs, like caching and security plugins.)

The P3 plugin's "Automatic scan" has a tendency to test more pages with events than other pages, in my experience with it. If you want to do a fair test you really need to do a manual scan. Usually people will visit each page in their main menu during a manual scan. Even then the Event page might still be a bit higher than others, but likely nowhere close to its current spot. One of the reasons why The Events Calendar is higher up on P3's profiles is because we hijack the main query on event pages. This limits the amount of time associated with WP itself on those graphs, but correspondingly increases The Events Calendar's time.

You mention you have other plugins who are resource hogs. To be blunt, our plugin should also be counted among resource hogs. We take performance extremely seriously, including regular performance audits and optimizations. But we can only be as fast as the WordPress APIs we're using, and truth be told post_meta is absolutely awful at handling dates. We have to be very conceed about performance to run as fast as we do.

There is a resource usage problem reported on your support area, but the topic is closed. No resolution was posted. The conversation continued over email: https://theeventscalendar.com/support/forums/topic/high-cpu-load-so-isp-shut-down-calendar-plugin/.

The problem in that topic comes our Month View Cache not yet having a throttle. When you enable month view caching in WP-Admin > Events > Settings > Display it will cache the months that you view, lessening the number of queries done for a given month view by many fold. But, when someone unleashes a spider on your website this can cause the site to cache many thousands of month view pages, eventually making the database cache gigantic. Typically this only happens when a malicious party is scanning your website for vulnerabilities, as most spiders will obey the <meta> robots tag and not spider month view pages. Definitely an edge case but one we're working to address. So far 3 people (out of 400k) have reported that problem and so we have it logged in our bug tracker as needing a fix.

Do you have Month View Cache enabled (in WP-Admin > Events > Settings > Display ) You can solve this particular problem by "clearing WP Transients" and disabling month view cache. I would leave it disabled until we release an update with a proper fix.

If you do not have month view enabled, would you mind trying a different performance plugin? P3 is decent for a super general overview, but lacks the accuracy and detail needed to zero in on performance problems. I highly recommend Query Monitor, but as with many super useful tools it has a leaing curve. Query Monitor will break down each query made when visiting a page such as /events/. It will tell you which queries are taking a lot of time, how many queries, what type they are, etc. Given that this is the public wordpress.org forum I am somewhat limited in how I can directly help you use this tool, such as logging in with it or requesting that you post copies of its output here. But, if you fire it up does anything stand out to you as being suspicious? Is there anything in its output that you feel comfortable sharing publicly here?

Cheers!
- Brook