- This topic has 22 replies, 5 voices, and was last updated 7 years, 2 months ago by
.
-
Posts
-
Hi Im getting slow query issues with my site using your plugins. Siteground tells me a lot of it from your plugins.
Sorry to hear this, @Jessica!
1. Can you share with us how many events are on your site, roughly? Nothing super-accurate necessary, just an estimate: Do you have thousands of events per month, for example? Or just a few dozen, perhaps? If you can clarify this and also share a link to your events page, that will be helpful.
2. Next, please share your site’s complete, un-edited system information using the “Sharing information manually” steps outlined in this article: https://theeventscalendar.com/knowledgebase/sharing-sys-info/
This data will help me take a closer look and will hopefully help me provide some recommendations for you to improve performance.
— George
Howdy Jessica,
Performance is an enormous passion of mine, and so George roped me in on this topic!
Thank you for sharing your system info and hosting details. That is very helpful.
I would like to start out by elaborating on what George meant here:
It’s true that some of the queries in our plugins are not as effective and optimized as they could be, and there is an active initiative to improve a number of queries in our plugins.
We work extremely hard to make our plugins as performant as possible. We do regular performance audits and optimizations. Any time we discover an area that’s not quite up to speed, we file a bug ticket and address it ASAP.
The primary reason why we do this is because WordPress best practice imposes an enormous handicap on “post meta date queries”. In short, WordPress best practice dictates that you store as much information as possible in its postmeta table, including dates. But, unfortunately this table is not optimized for dates. Any date query is literally hundreds of times slower than it could be. As you can imagine, calendars have to do lots of date queries!
Due to this handicap any calendar built following WordPress best practice, ours included, is operating with an enormous handicap. To overcome this, one has to work extremely hard to keep make the plugin performant, and we do.
Misc Bugs – Do you think any of these impact you?
When George said there was some inefficiency in our plugin, he was specifically referring to a couple of bugs we’re working on.
- Minicalendar widget does some unnecessary queries. Are you using the Minicalendar widget anywhere on your site? If so, for now can you try disabling it?
- Event Tickets does not paginate the Attendee list. Do your events have hundreds or thousands of attendees?
Month View Caching
Further, I see that your primary view is Month View, and that you do not have the Month View Cache enabled. Month View is a very beautiful and useful view. However, due to the nature of that view it can show considerably more posts than the average WordPress page. In WordPress, most pages show 20 posts, depending on your settings. But, a month view can show 6 weeks of events, and up to 3 events per day. Thus, it can show well over one hundred posts on a single page!
In your case, based on the numbers you have shared you have an average of 20 events per week. Thus, Month view is trying to show 5-6x the regular number of posts! You can expect it to be about that much slower than a regular page.
To help compensate for this we have a built-in cache for Month view. It can be found in WP-Admin > Events > Settings > Display with the name “Enable the Month View Cache”. Do you mind checking this box and hitting “Update”.
After you have enabled the cache, would you mind pasting the following snippet in your theme’s functions.php file? This will disable JSON+LD on Month View, which will further speed up the site when caching is enabled.
https://gist.github.com/elimn/9ce1c3e64d060b758e22627b815455ae
Once you have both of those in place, it will drastically cut back on the performance impact month has. While Month still has to render 120 events, it will only have to do this once. It will then store all that hard work and use it for each subsequent viewing of the page. When you add or update an event, it will redo the hard work and store it again. This will help performance on a site with a lot of events like yours.
Your Host
I really value these logs you have shared. There are some strange anomalies in them. 4 of them are caused by our calendar, the rest are not. The majority of them are some of the simplest and fastest queries imaginable. They are straight forward option queries like this:
SELECT option_name, option_value FROM wp_options WHERE option_name = value;
This sort of query should literally take about 0.001 seconds. On my server just now it took half of that time. But on your server it is taking over 5 seconds! That is not normal.
Presumably your host is heavily throttling your entire site, causing even the simplest of queries to be logged as slow. When this happens it becomes difficult to tell what the source of the problem is. It is very possible that the calendar is only a small part of it. I have seen some host support reps blame the calendar without truly investigating. Usually they see that our queries contain more characters than average, and thus just assume this is a problem. But that is an inaccurate assumption in many cases.
Your Database
Would you mind logging into your hosts Database Manager, which should be PHPMyAdmin? From there, could you take a screenshot of your database tables, and include the Records and Size columns in it? Then share the screenshot here.
I am interested in particular to see if the wp_options table is unusually large. Usually it is the fastest table in the database, and yet in your logs it was one of the slowest. Here is an example screenshot of what I’m looking for:
My main goal here is to get the calendar running as fast as it reasonably can on your current host. If from there your host is still throttling or suspending it, you will only have a few options left:
- Delete as many posts from your site as you can, including events. Also delete comments, and any plugins you don’t need. In general remove everything you possibly can to fit inside of your hosts performance envelope.
- Decided whether or not you want a WordPress calendar. Any one built according to WordPress best practice and contains 4300 events is just going to run too slow on your host. If you can do without a calendar, or are interested in switching away from WordPress…
- Find a different host. There are ample hosts out there, and I can think of a few that shouldn’t throttle or suspend you like that. I do not in any way wish to detract from Site Point, they seem like a decent host. But, there are other options which should not face this specific issue you’re seeing.
Please let me know if you have any questions of your own.
Cheers!
– Brook
- The topic ‘Slow Queries Causing Hosting problems’ is closed to new replies.