When saving menus, conditional purging greatly impacts performance.
greenbeemedia opened this issue · comments
Apparently since menus are made up of many posts, and the purge function of the helper is post type agnostic, when you update a menu, the plug-in will generate many purge requests depending on what settings you have, seriously slowing down the saving process for menus.
When the menu is large enough it results in excessively long execution times and time-outs if you are using nginx or php-fpm. With the plug-in turned off, it's near instantaneous saving.
I think that perhaps this plugin should discriminate against trying to purge for every menu item type post deleted or modified while saving or updating menus. It would make much more sense to purge the home page for instance, only after all the menu items that have been update/deleted/added, and to do so only once, rather than what it is doing now, for every menu item.
I've had to disable the plug-in to work on my menus, I think I will probably write you guys a patch to exclude menu post types from this kind of behaviour. Spent over 3 hours today diagnosing this thinking it was a problem with my nginx setup and max_input_vars in php.ini.
It might even make sense to be able to choose default/specific behaviours based on the post_type. For instance, if your site is hosting WooCommerce, it would make absolutely no sense to purge the home page or the post itself if you've added a weborder. Order changes in the back-end have no impact on the website's front-end unless the user is logged in, in most cases. This should definitely be a feature, otherwise it will be very cumbersome to use this plug-in on a high availability e-commerce site.
@greenbeemedia I think we missed menu condition. Thanks for explanation and offer to send PR.
I have few points to add - whenever menu changes, will you need to purge cache for entire sites? Because changes in menu can mean entire site will change.
If you need to purge entire cache, it can be done efficiently.
Also, are you using NGINX fastcgi-cache or redis-full-page cache https://easyengine.io/blog/easyengine-3-3-full-page-redis-cache/ ?
The setup I have been testing for the last few days is a LEMP server running nginx + php5-fpm, configured to use a microcache. I cobbled together the config from a few sources, mainly the WordPress Codex as well as another article for how to setup HA WordPress on a low-end VPS.
And yes, I agree, if the menu changes, and the menu is assigned to a site-wide template, it would make sense to purge the entire cache, if the menu isn't assigned, then it might not make sense to do so. Sometimes custom menus are used in shortcodes, and they do not show up in the menu admin page, so this is hard to predict, but then people can always just purge manually.