|
afermtools
|
May 3, 2017 at 6:04 pm
Hello,
The issue seems to have started yesterday evening, and strangely, it appears to be affecting only two events of the ~30 we have. Basically, attempting to load these events on the front end (and sometimes the back end) is very very slow, and sometimes throws 500 errors. That seems also to be the case with pages that load these events, ie, if they’re called into a list via shortcode on another page.
We’ve been building out these events, which both have numerous tickets and DateTimes, for a week or so, and till yesterday, they seemed to be working fine. We’re also transitioning to EE4 from Events Manager, and our webmaster manually imported the Events Manager events over this morning. None of those events have tickets associated, and seem to be loading fine.
What may have changed? Yesterday one person on the team mentions having experimented with the EE4 mobile app from the Google Play Store, and scanned a test ticket. He was unable to scan it a second time, becoming concerned that scanning may not work more than once for a ticket with multiple DateTimes associated.
Perhaps what he did caused the problem? Not clear, but we’ve tried looking at a few other things, and have no idea.
We’re using EE4 4.9.37.p on WordPress 4.7.2, with a child theme of the Memberlite theme by PMPro active.
Any ideas why we might be having the problems?
Thanks.
|
|
Josh
|
May 3, 2017 at 10:10 pm
Hi there,
The ticket scan would not cause the 500 error or slow load times. Can you check with your host to see if they made any updates or changes to the server’s configuration?
The other thing to check is whether the server is running low on memory. If the server runs low on memory, then some requests may slow down and halt if the server runs completely out of memory. In which case you can try to bump the memory limit by following this guide:
http://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP
|
|
afermtools
|
May 4, 2017 at 12:59 pm
Ok, thanks. I’m going to try the memory bump first to see if that fixes.
|
|
afermtools
|
May 4, 2017 at 3:52 pm
Ok, I raised the PHP memory limit to 64MB via WP-Config.php. That didn’t help. In fact upping it to 96MB seemed to make the site run slower. So I set it back to 64MB. We’re hosting via Godaddy on Linux, if that helps. Running PHP 5.4. Any help appreciated as this issue is bottlenecking progress on the project. Thanks.
|
|
Josh
|
May 5, 2017 at 7:14 am
64MB and even 96MB is actually quite low for running a WordPress site with plugins.
Did you check with Godaddy to see if they made a change to the server configuration recently?
|
|
afermtools
|
May 5, 2017 at 7:16 pm
I got on the support line with Godaddy, and they suggested creating a php.ini file with the desired memory limits. The contents of the file are:
upload_max_filesize = 128M
post_max_size = 128M
max_execution_time = 300
I’ve also set the memory limit in WP Config to 128MB. The performance issue is unchanged. They mentioned that a corrupt scripting or .htaccess file might be the problem, but I’m not quite sure where to begin with that, or if going down that rabbit hole would even solve the problem.
Any help would be appreciated.
|
|
Josh
|
May 8, 2017 at 8:25 am
I’m afraid the recommendation from Godaddy for the php.ini file edits will not help avoid 500 errors. You’ll actually need to add this to your php.ini file:
memory_limit = 256M ;
They mentioned that a corrupt scripting or .htaccess file might be the problem, but I’m not quite sure where to begin with that, or if going down that rabbit hole would even solve the problem.
That’s good advice. You can temporarily rename the .htaccess file on your server, then go to WordPress > Settings > Permalinks, then save and that will create a new clean .htaccess file. You can rule out a corrupt script by temporarily deactivating all other plugins
|
|
afermtools
|
May 8, 2017 at 2:49 pm
@josh, thanks for the support. I’ve made the addition, moved the php.ini file from wp-admin up to the root directory and upped the mem limit wp-config to 256M. Hopefully that does it. Waiting for things to propagate and crossing fingers.
|
|
afermtools
|
May 8, 2017 at 5:20 pm
Ok, about 2.5 hours later, no diff in performance. A couple of added notes:
1) The events that are running slow.
The slowest:
20+ Datetimes
8 tickets.
2nd Slowest:
<5 Datetimes
4 tickets.
Everything else I think has only one datetime and one ticket, and loading is not an issue.
Could there be a correlation?
Additionally, we’re running Events Manager plugin on the site. We’re migrating all of that content to EE4, at which point we’re going to disable Events Manager. Could that be causing the issue?
Thanks.
|
|
Josh
|
May 9, 2017 at 7:12 am
They all may be contributing (the additional tickets and other event plugin). You might also consider moving your site to one of the recommended hosts listed:
https://eventespresso.com/requirements/
We generally do not recommend Godaddy hosting because of the many issues they continue to have with hosting dynamic WordPress sites.
|
