Support

December 29, 2023 at 11:34 am

Hi there,

If you check your server error logs and look at the timestamps for around the time your getting the above error, does it show any errors?

The batch process is there to process 50 rows at a time which should prevent timeouts in most situations, so we’ll need to know the error being thrown on the request to troubleshoot this further.

December 29, 2023 at 3:13 pm

There are no errors in the log related to EE.

So the server throws an error and just doesn’t log anything at all? That doesn’t sound right, PHP timeout errors (if that’s what you are running into) would still show in the error logs.

And WPEngine says that they can’t increase the time limit for us.

Which time limit? I didn’t ask you to increase any time limits?

Is there another way we can accomplish this?

No, using the built-in routines to delete an event ensures that all related is removed and nothing is left orphaned, so this is the the way to delete the data correctly.

It seems absurd that this database would be over 2.5GB…

The more registrations, the more data we need to store, having a 2.5GB database for an e-commerce site (which is what EE is) is relatively small.

we’re going to need to find a way to address this.

We don’t know what the above issue is yet to be able to address it.

—

Here is what I would do from this point to help troubleshoot.

First, enable WP_DEBUG_LOG using this snippet:

https://eventespresso.com/wiki/troubleshooting-checklist/#wpdebug

You add that to your sites wp-config.php and the snippet replaces something like this:

define( 'WP_DEBUG', false );

It tells WordPress to store all errors within /wp-content/debug.log

Then, set yourself up to delete an event but right before you click to delete it open up dev tools on your browser and open the network tab.

Now your browser will log the ajax requests being sent to the server, to give an example, when you get to this point:

https://monosnap.com/file/4Iu7lIdA0BQw0HYmHf988og0f5Rg8F

Open Dev Tools (I’m using Chrome), then network tab:

https://monosnap.com/file/AlVcmTVjXrZObEVypl8pTdfQN5dp8A
(Side note, make sure ‘Preserver log’ is check, its to the right and down a little in my screenshot)

As the job processes, you’ll see multiple Ajax requests:

https://monosnap.com/file/veZZBldrIv0qlUVTBbYrpVglnSNr1R

When the process fails, that ajax may show you more details, click on it and view the headers tab and preview, any additional details there?

January 3, 2024 at 12:02 am

Were you able to do what tony recommended? Do you have the screenshot of error logs and screenshots of the dev tools?

Thanks

January 3, 2024 at 6:26 pm

Do you have staging site, where we can do this deletion?

If you do, please fill this form https://eventespresso.com/send-login-details/

thanks

January 4, 2024 at 3:36 am

The problem is we need some kind of error to know what is happening, even when PHP hits a timeout it stores an error stating the timeout has been exceeded within the PHP error log, or if the limit is on the web server, the access logs should show ‘something’ (likely a 502).

WPEngine has a 60-second PHP timeout and anything running on the individual delete request(s) should be well and truly finished within that timeframe.

I run multiple different server types for testing (ranging from really cheap shared hosting to my own dedicated server) and the one I prefer testing on the most for issues like this is the cheapest shared hosting option I have (less than $3p/m but I still consider them ‘good’ in the shared hosting platform) simply because if it runs on that it’s likely to run on pretty much anything above it. So on that hosting I’ve just created an event and imported over 2000 registrations onto that event to then delete it without any errors.

My point here is not “it works for me so this is your problem” but rather to show that this isn’t simply a case of EE is deleting too much on a single request and needs to be changed. We already batch process the delete requests and each of those processes above finished within 1-2 seconds for me. If we were pushing the process too far then we’d be looking at being much closer to the timeout waiting for each request to complete, especially on cheap shared hosting.

Now, having said that I was wrong above with the batch size being 50 rows. The default value for batch processes is indeed 50 rows but deleting values from the database is ‘cheap’ and when you have the ID’s of the rows you want to delete (which we do at the time the request is run) is very quick. So we actually increase the batch size for deleting by 10, so 50 * 10 = 500 rows per request (again, the cheap hosting shows that is not very expensive to run on each request). The value is filtered so it is possible to reduce that and test by setting the default batch to say 10, meaning 100 rows per request.

We batch process the delete requests and show a preview of the data we found to be processed before we run them, that preview can actually be more ‘costly’ than the delete requests themselves (meaning if the preview works, the delete should work if it’s a resource issue).

—

With all that said, I’m more than happy to investigate this further and see if I can track down what is happening. However, to do that I’m going to need access to the site/DB in some form, you needed to delete your staging site due to file size so that’s not an option currently and I’m not running any testing on the live site.

Would you be ok with me installing a copy of the site locally to see if I can reproduce this there?

January 4, 2024 at 3:18 pm

The diagnostic_log table is from the MemberMouse plugin you have installed on the site, that’s logging all PHP errors/warnings/notices to the database on every request.

If there is an option to disable that within the plugin, I recommend doing so, and then clearing out that table.

January 4, 2024 at 7:01 pm

No worries, the tEEm is always here to help you.

have a wonderful day!

thanks