Home › Forums › Calendar Products › Events Calendar PRO › Events Calendar Db causing huge server strain and slow downs
- This topic has 8 replies, 4 voices, and was last updated 9 years, 8 months ago by
Joanna Love.
-
AuthorPosts
-
July 25, 2016 at 5:45 pm #1143911
Joanna Love
ParticipantHi guys,
We have been having issues with the size of the events calendar Db and it putting a huge strain on our servers. This is worrying considering we don’t have a huge amount of traffic to our site just yet.
We do have a very large calendar of events (24,558 events – single and recurring so far)
Do you have any suggestions as to what we can do besides offsetting it by making the server more powerful? (which we have already done once before)
Seems like a bandaid solution as our calendar is only going to get bigger from here.
Thanks in advance.
JoJuly 25, 2016 at 6:18 pm #1143932Joanna Love
ParticipantJust to give you guys some figures on what we are currently using:
10gb out of 16gb ram is being used.
We were sitting at 90% usage on 4 CPU cores when there’s users on the site. Of that 320% of a possible 400% of the CPU load is the database process.
July 25, 2016 at 9:26 pm #1143997Cliff
MemberHi. Sorry you’re experiencing this and thanks for your efforts thus far.
There might be some new updates available. Could you please make sure all your Modern Tribe plugins (and WordPress core) are at their latest versions?
Once you verify you’re on the latest versions, please test to see if the issue is still happening for you.
If it is, please follow our Testing for Conflicts Guide (basically switch to TwentySixteen theme and deactivate all plugins and custom code other than Modern Tribe plugins) and see if that helps narrow down the cause of this.
If it doesn’t, please enable WP_DEBUG and WP_DEBUG_LOG and share any PHP errors you see while changing tickets quantity, navigating your site’s home page, events page, single-event pages, and any other of your site’s pages relevant to this ticket.
Then, please share your System Information (while in Testing for Conflicts mode).
You might also see if you can spot any console errors at your site. (If needed, you may reference our KB article Using Google Chrome Developer Tools.)
===
You might also consider reducing the number of months to cleanup past events and to go forward for new events in a recurrence series: wp-admin > Events > Settings > https://cl.ly/0P0b3o3P1D3F
===
It’s hard to tell if this is your issue or not, but please do strongly consider trying out this temporary plugin fix for runaway recurring events (a bug introduced in version 4.2.2 and fixed within a few days via version 4.2.2.1). If you do try the fix, please do follow the instructions carefully and allow time (maybe 1-2 days) for it to work its fix into all your events.
Please let me know how it goes for you or if you didn’t try it.
===
Let us know what you find out.
Thanks.
July 26, 2016 at 5:01 pm #1144435Joanna Love
ParticipantThis reply is private.
July 27, 2016 at 8:36 am #1144666Cliff
MemberThanks for the info. I had one of our developers take a look at the information you’ve provided thus far and here were the thoughts we had:
- 10 of 16 GB does seem very high. We know of scalability issues when you go past a certain tipping point (but that’s different for each server/site setup — we’ve seen sites operating fine with 20k, 50k, 100k events), and we’ve made a lot of improvements and will continue to make more.
- Are you running Apache with mod_php (slower) or PHP-FPM (faster)?
- How is MySQL set up? Which storage engines are in use? Have you considered adding extra indices? Is MySQL caching enabled (if it is, the size of the cache needs to be “just right” to be helpful)?
- We see you’re running W3 Total Cache, which can help the front-end, but does the server have any object caching (which can help wp-admin and which can help the front-end even more)? If object caching is available/active, if it’s configured incorrectly (like a really small 10MB), it could actually be more of a hinderance than a help.
Really, these are questions to possibly help your host / server admin. We cannot help with any of these sorts of issues.
===
I did see that the enable_month_view_cache setting is enabled, but the only calendar view you have enabled is the Map View. Have you tried other views and experienced the same loading issues?
Do you notice loading issues at Event Category pages or Single Event pages?
Does your site display any WP_DEBUG messages (or if WP_DEBUG_LOG is enabled, the file at /wp-content/debug.log)?
August 9, 2016 at 11:25 pm #1149864Joanna Love
ParticipantWe are currently on mod_php, we will be migrating to php-fpm soon. The distro we are using is giving us issues with fpm so we are rebuilding on ubuntu.
The db storage engine is InnoDB, is there a better one to use for calendar performance?
The mysql cache is currently enabled and set to 128M, is this to small/large?
The Events Calendar is now using so much system resources that if we get multiple people on the site at once it completely crashes the server and it needs to be restarted.
August 10, 2016 at 12:42 pm #1150164Cliff
MemberI didn’t see mention of an object caching (like memcache). That was the fix for another client in the past and might help fix things for you too.
While we do aim for our plugins to always be performant, there are situations where things could need extra attention. We do not provide this service, but you could reference our list of known customizers. Donny Grover (on that list) is usually pretty successful helping with these sort of things.
I hope this helps.
September 1, 2016 at 9:35 am #1158841Support Droid
KeymasterHey there! This thread has been pretty quiet for the last three weeks, so we’re going to go ahead and close it to avoid confusion with other topics. If you’re still looking for help with this, please do open a new thread, reference this one and we’d be more than happy to continue the conversation over there.
Thanks so much!
The Events Calendar Support Team -
AuthorPosts
- The topic ‘Events Calendar Db causing huge server strain and slow downs’ is closed to new replies.
