|
Freddys
|
October 26, 2016 at 10:58 am
Hello,
I keep having transactions from time to time now show up across in Infusionsoft. I think the problem may be due to high server loads. I was initially told to increase my memory on WordPress, but it was already much higher than I was recommended.
I then contacted. WPengine, by hosting provider, and was told that I am making many database calls which is eating up my resources. I will paste below what WPengine has said. Any help with this would be greatly appreciated!
—
Thanks so much for reaching out to us! As we discussed, I increased your memory limit to 1024M, but also found that your server levels were on the high side and you were using almost max memory.
I noticed that the install is processing nearly 26 gigs of information through autoloads. Here is the list of the autoloads.
—
Autoloaded / Total rows in wp_options:
745 / 3,344
Looks like autoload is indexed. Yay!
Top largest autoload rows over 1000 bytes:
mysql> SELECT LENGTH(option_value),option_name FROM wp_options WHERE autoload=’yes’ ORDER BY length(option_value) DESC LIMIT 20;
930607 ee_config_log
685332 ia_app_data
318918 wdp_un_updates_data
294260 ee_core_routes4.8.36
253869 ee_core_routes4.8.33
253869 ee_core_routes4.8.34
253393 ee_core_routes4.8.29
116611 wpts_compat
111865 yst_ga_top_pageviews
53811 rewrite_rules
51457 ee_active_messengers
43373 wpf_options
41651 um_cache_fonticons
32841 wp_user_roles
15917 ee_caps_initialized
12999 ee_config
11395 um_options
10865 yst_ga_source
10396 iw_bgp5_logs
10025 cron
Total autoloaded data (in bytes):
mysql> SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = ‘yes’;
3,679,092
We want that total to be under 800k or so for good performance.
This is ~2,879,092 bytes larger than 800k… Not ideal.
This is actually over 2mb – Definitely not good.
|
|
Josh
|
October 26, 2016 at 11:24 am
You can actually delete the ee_config_log option, it’s not used and the next version won’t have that on by default.
|
|
amcfamily
|
October 27, 2016 at 12:47 pm
I have nearly an exact clone of this issue (including the same host and basically the exact same chat transcript). How would I delete the ee_config_log option, and do all the core routes need to run? Is there any database cleanup that could be done so other queries are not affected as well? We’re running the latest version of the plugin, apps, etc., and I’m guessing some of those routes are in there for backward compatibility with older versions.
|
|
Josh
|
October 27, 2016 at 1:24 pm
The routes are for the REST API. The very latest version of Event Espresso 4 that was released a few hours ago sets those routes to not autoload and deletes the ee_config_log option. You can update to the latest version of Event Espresso and it will take care of cleaning up those options.
|
