BUG: Outdated plugin cache transients waste database storage

  • Matthieu-P. Schapranow

    (@theschappy)


    2 months ago

    First of all, thanks for the great plugin — it tremendously enhances readability of long texts!

    Affected plugin version: 5.11.0

    Description: The plugin stores its cache as transient in the wp_options database table. Unfortunately, over time the list of transients is growing as outdated ones are not cleared. I have just removed 200M+ of outdated _php_hyphenator_cache transients. Especially for large pages with many text content this results in multiple problems:

    a) all _transient_typo_<unixtimestamp>_php_hyphenator_cache transients are marked as “autoload”, but only the one with the highest <unixtimestamp> might require to be marked autoload,

    b) outdated transients are consuming a significant amount of database storage, although they appear to be not used by the plugin

    c) transients tend to slow down php processing (due to autoload) and increase memory footprint of the php process, which might be a bottleneck for virtual servers.

    Possible solutions: After updating the cache, ensure in your own abstraction of the WP transient classes to remove all older transients of the plugin. Alternatively, you might want to consider creating a WP cronjob, which deletes outdated transient objects of the plugin once a day.

    Many thanks for your support!

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter Matthieu-P. Schapranow

    (@theschappy)

    2 months ago

    This is what I got 9hrs after cleaning up all caches (expect one) from the database: 175 cache records consuming 61 MB of DB storage as well as php memory consumption for each site request as they are all autoloaded.

    SELECT COUNT(*) as "Cache Records", ROUND(SUM(LENGTH(option_value)/1024/1024)) AS "Size in MB" FROM wp_options WHERE option_name LIKE '%php_hyphenator_cache'

    Thread Starter Matthieu-P. Schapranow

    (@theschappy)

    2 months ago

    I would like additional important observations: Affected WordPress instances have the W3 Total Cache plugin enabled with memcache as object cache and the option “Store transients in database” enabled. The plugin states about this option “Store transients in database even when external cache is used, which allows transient values to survive object cache cleaning/expiration”. I suspect that maybe W3 Total Cache add the transients with the expiry timestamp to the database and is not cleaning up correctly. I will also add a corresponding topic there and reference here.

    List of recent transient options:

    _transient_typo_1740565127_php_hyphenator_cache +476 secs.
    _transient_typo_1740564651_php_hyphenator_cache +195 secs.
    _transient_typo_1740564456_php_hyphenator_cache +189 secs.
    _transient_typo_1740564267_php_hyphenator_cache +216 secs.
    _transient_typo_1740564051_php_hyphenator_cache +256 secs.
    _transient_typo_1740563795_php_hyphenator_cache

    Plugin Author pepe

    (@pputzer)

    2 months ago

    Thank you for the detailed report. I’m not sure what the use-case for that W3TC setting is (transients are meant to be recreated if necessary), but it looks like that needs to be solved there. wp-Typography already cleans up the DB transients when no external object cache is in use.

    Thread Starter Matthieu-P. Schapranow

    (@theschappy)

    2 months ago

    Hi @pputzer ,

    thanks for pointing to the right location of the plugin’s caching code.

    In the particular setup, memcache is used by W3TC as object cache (and in addition transients of the object cache are stored redundantly in the database for whatever backup reasons). You perform a cleanup iff wp_using_ext_object_cache is not true. However, I suspect that W3TC will change it to true once an object cache is configured with it. I have disabled the option “Store transients in database”, which prevents outdated copies of the aforementioned transients to be mirrored to the database, i.e. php memory consumption and database load is back to normal.

    However, what about the outdated transients in the object cache? I suspect that it holds the same list of transients as mentioned above; how to remove expired copies off the object cache if there is no cleanup performed in case of wp_using_ext_object_cache is true? You leave this to W3TC to figure out how and when to remove them, right? W3TC offers an option for scheduling a cronjob to purge the object cache regularly (many options reaching from hourly to daily), which appears to be a kind of workaround instead of triggering timer-based removal per expire date for each and every transient.

    FYI: Here is the cross reference to my corresponding question in the W3TC plugin support forum.

    Plugin Author pepe

    (@pputzer)

    2 months ago

    Object caches normally operate LRU principles, so when a new object needs more memory than is available, the least recently used object is discarded (until there is enough free memory). Clean up after expiration is something the object cache needs to do, yes.

    WordPress does not have any processing going on outside of the request, so there is no way for a “timer” to trigger other than via a cronjob with a set granularity.

    • This reply was modified 2 months ago by pepe.
Viewing 5 replies - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.