Matthieu

Hey @pputzer,

The original problem is not addressed. For the time being, affected used should consider to configure the following work around:

1. Disable store transients in database setting in W3TC.
2. Configure the W3TC setting Purge via WP cron to cleanup outdated transients in a regular interval.

I have closed this thread: many thanks for pointing me to the right direction!

The author of the wp-typography plugin pointed out here that outdated transients are removed from the database by the plugin iff wp_using_ext_object_cache is false. I suspect that W3TC with configured object cache will alter this WP setting to true. As the plugin does not know how the specific object cache works, it cannot run removal operations. As a result, expired transients will be present in the object cache as well as in the database if the Store transients in database setting is enabled. Thus, disabling this options removes the redundant storage from database and reduces load on the database. Furthermore, I have now configured W3TC’s Purge via WP cron setting for the object cache to cleanup outdated transients from it as well; otherwise it might grow in a similar way like the database.

Thank @vmarko for the prompt reply. For the time being, I tested to disable the option “Store transients in database” to see if this is a work around. I expect to have no new transients added to the database now (I would consider this as the default option if not already, because I do not see any benefits from duplicating transients in memcache and the database at the same time).

For further investigation, here are some further settings:

• Default lifetime of cache objects: 180s
• Garbage collection interval: 600s
• Purge via WP Cron: off

Is garbage collection also running for transients stored in the database or only on disk as noted in the explanation? If the “Purge via WP Cron” task is scheduled, would this purge also the transients copies stored in the database; i.e. a be kind of regular cleanup task?

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

To summarize my observations up to now: WordPress admin users do not see any issues. Any non-admin users without the manage_options WordPress capability will receive a HTTP 403 for the jetpack REST API endpoint /wp-json/jetpack/v4/connection/data. Typically, you do not want to have non-admin users equipped with manage_options capability, because it basically allows to manage and change the majority of WordPress settings. This might be connected to the issue ticket from Jan 2024: https://github.com/woocommerce/woocommerce/issues/44009. I will link this thread there and request additional support.