wp_option table for input with autoload = ws_menu_editor

The admin menu configuration is used on every admin page, so it’s probably reasonable to have the autoload setting enabled.

If the size of the configuration is causing problems for you site, you could try making it smaller like this: go to the menu editor, switch to the “Settings” tab, scroll down to the bottom of the page and enable this setting:

“Compress menu configuration data that’s stored in the database”

I was going to ask a similar question. We had issues with loading our login page within WP Customizer. It was generating a 502 error on Nginx.

The hosting company looked into it for us, and noted that the DB Autoloaded Data is relatively high on our site. It’s coming in at 1,469,478 bytes, when 800,000 bytes is the recommended maximum.

An analysis showed that ws_menu_editor was loading the most, by a big margin.

+----------------------+---------------------------------------+
| LENGTH(option_value) | option_name                           |
+----------------------+---------------------------------------+
|               416009 | ws_menu_editor                        |
|               141378 | bfwc_default_settings                 |
|               108348 | wp_installer_settings                 |
|                63109 | fs_accounts                           |
|                58246 | asp_updates                           |
|                53651 | judgeme_widget_all_reviews            |
|                48781 | rewrite_rules                         |

etc.

I will test out the compression option. Is it likely to make a big difference?

Is there any way you can optimize the plug-in itself (in a future release), to require less DB Autoload Data? Perhaps there would be a way to save the menu order to a static file? As you know, the menu can be rearranged with a relatively small amount of code in functions.php file. So it seems it could be more efficient to cache the menu order settings to a static file, rather then having to read such a large amount of data from the DB every time a back-end page is loaded.

Regards,

Jonathan

• This reply was modified 3 years, 12 months ago by inspiredmind.

Enabling compression should make the entry significantly smaller. It will probably reduce the size at least by 50%.

There are certainly ways to further reduce the size of the configuration data, but each option that I can think of also has some signification trade-offs. For example, eliminating redundant fields and/or switching to a binary format would help, but it would also increase CPU usage because the code that loads the configuration would have to be more complex. I’m not sure if that’s really worth it.

Perhaps there would be a way to save the menu order to a static file?

Sure, that would be possible. However, this plugin has many more features than just changing menu order. It would take a huge amount of work to make the plugin generate a static file that can do everything, and it would probably produce a huge file that has to be loaded for every admin page – not much of an improvement.

Amazing! Was just looking into this!

“Compress menu configuration data that’s that are stored in the database”

@inspiredmind “Is it likely to make a big difference?”

From 584259 to 35819 = 94% compression!

Why is this not ON as Default? Never read that part of settings since the Heading is “Debugging”. May I suggest re-branding it and making it way more prominent?

Thanks for a great plugin!

//Matt

• This reply was modified 3 years, 11 months ago by Matt.

It’s not on by default because there’s a performance trade-off here. A compressed option takes up less space, but the plugin needs to decompress it before it can be used, which takes more time. There’s a risk that this additional time could exceed the time that was saved by loading less data from the database, which means enabling this option could actually decrease overall site performance.

I’m not sure how high that risk is; it will probably vary depending on the server.