[Henry Rankin]

Thanks Andras. I received a reply from Caroline at Support in reply to my sales enquiry (submitted through your site on 7/5/17). Caroline initially replied on 7/6 with a message that the product team was working on something and would get back to me within a week. I emailed her yesterday 7/18, after following up with you and got a message back today that Barry on the product team had emailed me. I never received it, so asked her to resend.

I’m not trying to create duplicate efforts here, just find a solution in the fastest way. Again, I would pay for a service or product that eliminates the massive SQL demand on my server and slows down my website.

[Henry Rankin]

Hi, it’s been about a week. Any updates on this issue? I’m currently evaluating other calendar options. I’d like to stay with The Events Calendar, if the massive drain on resources can be fixed. I’ve reached out to the Enterprise Sales team and just got an email 2 weeks ago saying that they’d get back to me in a week.

[Henry Rankin]

Thank you Andras,

I’m also attaching a screen shot of the resource load on the server at WP Engine when loading my site. As you can see The Events Calendar is a massive resource hog in transaction time. (the 3rd – Newspaper is our WP theme)

I’m also currently evaluating alternatives that might not be as unstable and resource intensive as the The Event Calendar. I do not want to change, but I may not have a choice. I cannot be the only publisher who needs to schedule events at this volume.

Your updates are welcome

[Henry Rankin]

1. I have a hosting package on WP Engine, designed for a million monthly sessions (we’re well below that right now). I expect your office is familiar with WP Engine, as some of your team was visiting their office in Austin back in May. The hosting service is optimized for speed, and per my notes above, are the ones who identified the problematic code.

In the attached image, you can see a chart of the transaction time on my site, once I updated the events calendar to the current version on June 28. It’s the action that started the spike in transaction time. (you can see the starting point on the far left hand side). The drop coincides with when I downgraded The Events Calendar to Version 4.2.7 & Events Calendar Pro to version 4.2.6.

(The dip in the middle of the peak transaction time came on July 4 when my account was given an emergency upgrade to handle all the transaction requests. As you can see, it still didn’t come close to compensating for the toll the calendar plugins put on the server)

Before moving to WP Engine, I was on a dedicated server, which repeatedly had too much demand on the CPU as a result of the Events Calendar (version 4.2.7 & 4.2.6). When we deactivated the plugins, the transaction time returned to normal.

2. I originally used Event aggragator but didn’t renew it and I deactivated it years ago. So it never ever runs. It also put too much demand on the server and was not worth the effort. I pay staff to manually create the event entries.

• This reply was modified 8 years, 10 months ago by Henry Rankin.

[Henry Rankin]

Here’s the input from WP Engine:

That query is fired on line 1017 on /nas/content/live/houston365/wp-content/plugins/the-events-calendar/src/Tribe/Query.php when viewing http://365thingsinhouston.com/calendar/shadow-puppet-theatre-woodlands-childrens-museum-2/2017-07-06/ The specific query itself is:

SELECT SQL_CALC_FOUND_ROWS DISTINCT wp_posts.*, MIN(wp_postmeta.meta_value) as EventStartDate, MIN(tribe_event_end_date.meta_value) as EventEndDate FROM wp_posts LEFT JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id ) LEFT JOIN wp_postmeta AS mt1 ON ( wp_posts.ID = mt1.post_id ) LEFT JOIN wp_postmeta AS mt2 ON (wp_posts.ID = mt2.post_id AND mt2.meta_key = ‘_EventHideFromUpcoming’ ) LEFT JOIN wp_postmeta as tribe_event_end_date ON ( wp_posts.ID = tribe_event_end_date.post_id AND tribe_event_end_date.meta_key = ‘_EventEndDate’ ) WHERE 1=1 AND wp_posts.ID NOT IN (73435) AND ( wp_postmeta.meta_key = ‘_EventStartDate’ AND ( ( mt1.meta_key = ‘_EventStartDate’ AND CAST(mt1.meta_value AS DATETIME) < ‘2017-07-06 11:00:00’ ) OR ( ( mt1.meta_key = ‘_EventStartDate’ AND CAST(mt1.meta_value AS DATETIME) = ‘2017-07-06 11:00:00’ ) AND mt1.post_id < 73435 ) ) AND mt2.post_id IS NULL ) AND wp_posts.post_type = ‘tribe_events’ AND (wp_posts.post_status = ‘publish’ OR wp_posts.post_status = ‘tribe-ea-success’ OR wp_posts.post_status = ‘tribe-ea-failed’ OR wp_posts.post_status = ‘tribe-ea-schedule’ OR wp_posts.post_status = ‘tribe-ea-pending’ OR wp_posts.post_status = ‘tribe-ea-draft’) GROUP BY wp_posts.ID ORDER BY EventStartDate DESC, wp_posts.ID DESC LIMIT 0, 1 /*
I hope this helps The Events Calendar dev’s gain more insight into the issue.

[Henry Rankin]

I’ve asked the folks at WP Engine to provide more insight into when that query is fired.

However, I can answer the rest. It affected every single page on the site. It was most difficult for me or any of my staff who were logged into Word Press, but even the general public was getting Error 504 messages. The Events Calendar plugin was creating a high volume of server queries and maxing out its CPU. This has been an ongoing problem of the plugin for us (We have 100s of events on a single day at times). This problem began on June 28 with I upgraded the Plugins from the following versions:

The Events Calendar – Version 4.2.7
The Events Calendar PRO – Version 4.2.6

When I originally updated the versions above in 2016, the new versions crashed our site. The heavy CPU usage began on the same date I tried upgrading the 2 plugins to the current version. I have downgraded the 2 plugins back to the older versions above and the problem has gone away.

That said, The Events Calendar plugins still place a heavier usage on the CPU than they should. As I understand it, it is partially because of the automatic linking of recurring events. I could be wrong on that.

I also have a request in to your sales department to identify what may be available for publishers like ours, that aggregate a high number of events for mass consumption.

[Author]

Posts