wp_load_alloptions() killing website

  • Hi WP forum,

    I’m hoping someone can help me with an issue I’ve been having regarding wp_load_alloptions() massively slowing down the speed of my site.

    I’m not a developer so I’ve done as much searching as I can to try and root out the problem and eventually managed to find what I believe to be the cause using the Query Monitor plugin.

    Query
    SELECT option_name, option_value
    FROM wp_options
    WHERE autoload = ‘yes’ wp_load_alloptions()

    Caller
    wp-includes/option.php:168-
    is_blog_installed()
    wp-includes/functions.php:1276
    wp_not_installed()
    wp-includes/load.php:474

    Affected rows
    1139

    Time
    137.5274

    If anyone is able to offer some insight into how to fix this issue, or if you require more information, it’d be great to hear from you.

    Many thanks

Viewing 2 replies - 1 through 2 (of 2 total)
  • senatorman

    (@senatorman)

    Here the same problem with the core.

    Iám using the Beta version 4.4-beta4-35707

    wp_load_alloptions()
    wp-includes/option.php:181-
    is_blog_installed()
    wp-includes/functions.php:1355
    wp_not_installed()
    wp-includes/load.php:496

    Affected rows 1596
    Time 2479 ms
    Component: Core

    Site is extreme slow since Version 4.3

    Paul Fernhout

    (@pdfernhout)

    You could add debugging code (in a test environment, using error_log) to log what all the options are and then look at the results. You ideally do not want to do this in a production environment as such debugging code would slow your system further. Alternatively, and maybe easier, you could use an interactive SQL tool (very carefully) to look at your production database to see what is being stored in the options data. If you’re not comfortable doing any of that yourself, you might want to hire an experienced WordPress consultant to do it for you.

    That might help in determining whether some plugin (or core code) is abusing the options system to store more data there than it should. A plugin might be, say, setting a unique option for every product or post or something like that, where a lot of data should otherwise be stored elsewhere to avoid exactly this sort of issue. If that is the case, then you could file a bug report on the specific plugin or core system.

    Of course, the issue could be from a totally different cause. This is just a general suggestion as a first thing to try for troubleshooting this.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘wp_load_alloptions() killing website’ is closed to new replies.