Performance/Query time

  • Resolved extremecarver

    (@extremecarver)


    3 hours, 40 minutes ago

    Analyzing the Timeline of my website – TOC+ is one of the slowest plugins to load – now of course this will only apply to logged in users – as non logged in get to see a cached page – but I wonder why the plugin seemingly (I may be wrong and misunderstand something) needs to run database queries on every page load.

    Overall the queries on my relatively plugin heavy site take about 0.20 seconds – But TOC+ alone takes around 0.01-0.02 seconds for it’s query. Yes it’s not render blocking so no essential slowdown as other queries are started in parallel – but I feel this is quite long for something not depending on external sources to load. And it’s the slowest query of all queries on my website by quite some margin. Most queries need only 1/10 of the time or less.

    The offending query is:

    UPDATE wp_options
    SET option_value = ‘1790366945’
    WHERE option_name = ‘_transient_timeout_aioseo_plugin_cache_table_exists’

    1. update_option()
      wp-includes/option.php:963
    2. set_transient('aioseo_plugin_cache_table_exists')
      wp-includes/option.php:1569
    3. AIOSEO\TableOfContents\Core\Cache->checkIfTableExists()
      wp-content/plugins/table-of-contents-plus/app/Core/Cache.php:76
    4. do_action('init')
      wp-settings.php:779
Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Support MM Aurangajeb

    (@aurangajeb)

    2 hours, 53 minutes ago

    Hi @extremecarver ,

    Thanks for reaching out!

    TOC+ checks once per request that its cache table is present, then refreshes a transient so the next request can skip the check. The refresh isn’t conditional, so it rewrites the transient on every request that reaches PHP. The stored timeout is a timestamp that moves every second, so WordPress can’t skip the write. I reproduced it here, and it’s actually three wp_options UPDATEs per request rather than the one you caught.

    Thanks for posting the trace. It made this quick to confirm. It’s now filed with our development team internally for further investigation.

    I’ll post back here when the fix ships.

    Thanks again for bringing this to our attention!

    Thread Starter extremecarver

    (@extremecarver)

    2 hours, 47 minutes ago

    perfect thanks. I simply guess it could be faster – and that would be great. Gives less importance then to various other performance / caching plugins.

    Maybe even the TOC could somewhat be cached and inserted by the plugin instead of generated on the fly on each pageload. Though maybe I overlook some reason why it needs to be generated each time instead of just when the page content changes.

    In the past I’ve had way more offending plugins, or my translate plugin still takes way more time – but not on a single (or triple) query.

    • This reply was modified 2 hours, 46 minutes ago by extremecarver.
    Plugin Support MM Aurangajeb

    (@aurangajeb)

    2 hours, 16 minutes ago

    Hi @extremecarver ,

    The TOC isn’t built from the stored post content. TOC+ hooks the_content at priority 100, after shortcodes and every other content filter, then parses the finished HTML in memory. No database query in that part, which is why it never showed up in your timeline.

    That’s also why it isn’t cached. The headings at output time aren’t always the ones in the stored content. Your translation plugin is the clearest case, since the heading text and the anchor IDs built from it change per language. A cache keyed on the post would go stale and start emitting anchors that don’t match the page.

    I’ll update the thread when the fix ships.

    Thanks!

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.