Database Transient cache keeps blowing out of proportion

Hi,

Update:

Count	MB	Hours
Form Selects:	2	0.5	720.0
Head Markup:	10309	72.4	168.0
Image URL Info:	7	0.0	24.0
Schema Indexes:	29	0.1	720.0
Shortened URLs:	0	0.0	2160.0
Video API Info:	0	0.0	24.0
All Transients:	10351	73.1

Updating the plugin seems to have ‘slowed’ down the bloat, but it keeps growing.

10k head markup transient cache objects would suggest 10k unique URLs, without counting date based archives. Does 10k unique URLs sounds correct for your site?

js.

Note that when clearing and refreshing the transient cache, WPSSO re-creates cache objects for all posts, terms, and users. Additional cache objects may be created for other URLs as they are requested, but not for posts, terms, users, 404 pages, search results, or date based archive pages (since they have already been created, or are excluded from being cached).

You originally reported 646 cache objects for posts, terms, and users, so I wonder what additional pages on your site would have created about 9k+ cache objects (without them being 404 pages, search results, or date based archive pages). Any ideas?

js.

There are 9347 records in the wp_posts table now and most of the ‘urls’ in guid are for ‘attachment’ post_types.

The site’s sitemap shows around ~7000-8000 attachment ‘urls’ and a considerable amount of ‘urls’ for ‘post tags’ (here I think it could be the post tags which could be the problem).

WPSSO creates a transient cache for meta tags and Schema markup for public posts (posts, pages, attachments, and custom post types), public terms (categories, tags, and custom taxonomies), and public users (authors).

If you have about 10k unique URLs, then 10k transient cache objects would sound correct.

Like the new “Caching for Date Archive Pages” option, I could add a “Caching for Attachment Pages” option in the next release. Typically, without a cache object, the meta tags and Schema markup creation process takes about 0.03s compared to about 0.006s with a cache object. Since attachment and date based archive pages are not accessed much by typical visitors, this may be acceptable (0.03s in a typical 2-3 second page load time is still pretty good, but 0.006 is better). ??

js.

Yes, you are correct about the load timing. But, in a limit starved shared hosting for a simple site like this could be a problem if the database size goes beyond a certain limit. I think, the option for caching for attachment pages would be a good idea, similarly, if there was an option to toggle on/off for tags (particularly in this case) it would almost resolve this issue.

Or could that be done by code?

I’ve added a new “Cache Attachment Markup” option (disabled by default) in WPSSO Core v8.32.0-dev.1. You can download the latest development version here: https://www.ads-software.com/plugins/wpsso/advanced/

You can also disable head caching globally using the filter I provided earlier.

js.