Site Slows to Crawl Since Upgrade(s)

[Cliff]

Krystal, thanks for sharing and, yes, please create your own ticket if you haven’t already.

[Andy]

I ran the CRON job immediately upon re-activation via WP Crontrol with no luck. Still have over 21,000 events.

Can you please give me information about the $wpdb->posts and $wpdb->postmeta post types and key/value pairs to look for to find (and subsequently remove) the expired events?

I take full responsibility for my database actions and can write the SQL myself, just need a short narrative of what fields hold what (specifically the event instance date/time) so I can delete anything before today.

[Barry]

Hi Andy,

The postmeta for each event will contain a number of fields including _EventStartDate and _EventEndDate – the latter is probably the optimal choice here when looking for expired events (as of course valid, ongoing events may have a start date in the past but an end date in the future).

Basing your selection of post IDs on that field would be the basis of a cleanup query, which might look something like this:

https://gist.github.com/barryhughes/5e2b04e57d1f407a8e2f

That will leave a number of “orphaned” records in the post meta table which would also need to be cleaned up, but should show the basic approach to detecting and removing expired events.

Please do review and perform a test run on a test site before using on production data and of course make a backup that you know you can restore before doing this work!

Does that help at all?

[Andy]

So, I played with this and just restored our tables and re-ran “SELECT * FROM wp_posts WHERE post_type=’tribe_events'”

It returns 1053 total posts.. but our Event’s listing in the admin still says 21,753 – any thoughts?

The query kind of wiped out all posts, so I had to revert.

[Barry]

Hi Andy,

I’m not completely clear if there are still just 1,053 (event) posts in your db or not as you mention having reverted – but my guess would be that the count you are seeing in the admin environment is cached.

(wp_count_posts() – which is used to obtain that value – caches it by default in order to reduce overhead and by directly modifying the database it’s quite possible the cached value was not invalidated.)

Assuming that is indeed the problem, can you trying clearing your cache and see if that helps?

[Andy]

Barry – clear what cache? Browser cache? We do not have a caching plugin or caching installed on the server. I am unaware of internal cache’s running within WordPress by default that we have a UI to clear? Please clarify.

[Barry]

Hi Andy,

Sorry for any confusion – I was incorrectly jumping to a conclusion there 🙂

If you don’t have any caching mechanisms in place (and assuming you’re not on a managed hosting platform that provides this “transparently”) then I may have been incorrect.

With all that said, what query exactly did you run to remove the expired events? It sounds as if the query I provided didn’t work as expected for you and that you may have amended it?

Additionally, have you tried adding a new event (and subsequently trashing/deleting it) – and does that influence the total post count you see in the edit events screen?

Thanks!

[Andy]

Barry, I got the “real” count from:

SELECT * FROM wp_posts WHERE post_type = ‘tribe_events’;

It’s about 1,095 or so; but I even creating / deleting a new event (“Mine (1)” displayed while it was created) – “Trash (1)” displayed after trashing;

More interesting: When viewing the trash for Tribe Events, it says there are “no events found in trash”

Thoughts?

[Barry]

Difficult to say; but as an alternative you could always revert to your backup and ‘manually’ delete expired events in batches.

The screen options pull-down tab lets you increase the number of events shown per page in the admin environment, so you could delete in batches of 100 (or even more than that), which while still slightly time consuming wouldn’t be too arduous a task – you could certainly make a big dent that way and you’d know that the delete operations were being done the “WordPress way” as opposed to directly modifying the database.

I’m afraid that not being able to replicate the issues you are describing, it’s difficult to provide much in the way of further insights.

[David]

I am having the exact same issue. At times, it take me 1-2 minutes to publish an event, after which I have to clear the cache on our site… or the site is basically unaccessible.

We just started using the plugin in November. We have nearly 50-100 events so far, and we are hosted on a private server.

I noticed the issue with speed about 2-3 weeks ago.

[Barry]

Hi Allyson,

Please do create a fresh topic of your own and we’d be happy to look at the problem as it is in your specific case 🙂

Thanks!

[Andy]

Do, how do I know if I’m deleting the entire recurring event or an instance?

[Barry]

You mean in the context of deleting events via the admin list?

If you hover over a given (recurring) event the link will either read as Trash if it is a single event or Trash Series if it is the base event (in which case, as the link implies, it will trash the entire series).

By default there is a column indicating if events are recurring, so you could quickly mouse over those and de-select any that are base events.

[Andy]

Barry,

This effectively takes us back to square one. What I’m seeing:

• Either the plugin is incorrectly reporting the events, or they are stored some where other than a post WHERE post_type = 'tribe_events' – the plugin reports 21,000+ and the database says ~1,100.
• Given the database response, the queries provided won’t work as the posts don’t actually exists
• The CRON script is not running and does not remove events older than 2 months or later than 2 months as it still reports 21,000 even when the CRON tasks (2 of them for Tribe/Events) have been explicitly run multiple times and it’s been over a week.

What is the next step? We effectively have upgraded the plugin to have our site go down or eliminate all of that content from the site.

Everytime I have to turn on the plugin to test / run commands, I have a short amount of time before the MySQL server stops responding due to the queries.

Let me know, please.

[Barry]

Hi Andy,

Thanks for the update.

Based on your recent tweet I appreciate that you are concerned about the speed of support here on the forums – all I can really say is that we try to reply as quickly as we can.

During the working week we aim to provide responses within a 24hr window, but I think this topic demonstrates nicely that we frequently exceed that target by quite a large margin (though there were admittedly one or two longer delays due to outages over the Christmas/new year period at the start of the topic) and same day responses within the space of a few hours are not uncommon.

If you still have concerns about the frequency or level of support we provide then we’d be happy to discuss that in more detail, however I would not wish to derail this topic – for that reason I’d invite you to email us with any non-technical or customer service related concerns:

support [at] theeventscalendar [dot] com

Thanks and I’ll follow up in a separate reply with regards to the current technical problems you are experiencing.

[Author]

Posts