Timeout to 502 when updating Recurring Event (Daily)

[Jen Russo]

FWIW, I’ve read: https://theeventscalendar.com/support/forums/topic/timeout-when-saving-recurring-events/

Most recurring events can be edited/updated. Several however, particularly those that repeat a lot (ie. daily) fail when updated, timing out after 60-90s and redirecting to an nginx 502 page at /wp-admin/post.php.

Like this one:
domain.com/wp-admin/post.php?post=40811&action=edit
screenshot of recurrence pattern: https://cloudup.com/cmlzHahXTOB

It doesn’t surprise me WPE kills long running PHP processes at 60 seconds, most hosts do. It does surprise me that TEC isn’t doing something to avoid this timeout though. I think there is something else that might be going on here.

I’ve cloned the site to WPE staging for testing. It fails there the same. I deactivated all the plugins that weren’t a Tribe Events plugin and reverted to the 2014 theme. I thought it worked the first time I hit update on that one post, but then on many many repeat attempts it’s failed, so we’ll call that first one a false success. Maybe I was on the wrong post.

FWIW, I did successfully update this post on my local install twice, each time it took 4 minutes (VVV, PHP5.5, 4 CPUs, 1024MB) with all plugins activated as normal the first time. Oddly after deactivating everything and trying again it ran 10 minutes before I killed it.

Note: The DB for this site isn’t small, but it’s not really big either. 12,000 posts, 6000 comments, 200 categories, 11,000 tags.

This is Jon Brown (developer) not the actual client/licenses holder. Outside this forum I can give you a url and login to staging if you need.

[Barry]

Hi Jon,

Thanks for contacting us.

screenshot of recurrence pattern: https://cloudup.com/cmlzHahXTOB

…

Note: The DB for this site isn’t small, but it’s not really big either. 12,000 posts, 6000 comments, 200 categories, 11,000 tags.

Thank you for sharing this – it gives us a much better picture of your setup and what you’re experiencing.

That particular pattern, if I’m reading it correctly, will result in 402 individual events – all stored in WordPress’s posts table. So, if you make an update, that’s 402 posts that need to be modified.

As you can imagine that is a lot of work and given this the timeout perhaps is not surprising.

It doesn’t surprise me WPE kills long running PHP processes at 60 seconds, most hosts do. It does surprise me that TEC isn’t doing something to avoid this timeout though.

That’s definitely a valid point. A few ideas come to mind but, as I hope you can appreciate, none are trivial changes and this is something we’re going to need to discuss before potentially taking further action.

In the interim would breaking chains of events up into smaller chunks be a viable workaround?

[Barry]

I’m going to close this thread out, but we’re working with WPEngine to assess issues like this and are monitoring the relevant support channel for this one.

If you need any other support here on the forum please don’t hesitate to create new threads as needed.

[Author]

Posts