Database Transient cache keeps blowing out of proportion

That doesn’t sound right. Please copy-paste the “WPSSO Core Database Transients” table in the SSO > Dashboard > Cache Status metabox.

js.

WPSSO Core Database Transients
               Count	MB	Hours
Form Selects:	0	0.0	720.0
Head Markup:	0	0.0	168.0
Image URL Info:	0	0.0	24.0
Schema Indexes:	0	0.0	720.0
Shortened URLs:	0	0.0	2160.0
Video API Info:	0	0.0	24.0
All Transients:	0	0.0

This is the info. But, I had run clear caches from the plugin and there are no transients in the database for now.

But, they will be back in a day or two.

Please copy-paste the table values again in a day or two.

js.

BTW, you can click the SSO > Tools and Actions > Refresh Transient Cache button to re-create all the cache entries for post, page, user, and term markup.

js.

If you can click that button, wait a few minutes for the cache to refresh in the background, then copy-paste those transient cache table values, I can offer some additional insight. ??

js.

Hi,

The below is ~1 hour after clicking the refresh button:

               Count	MB	Hours
Form Selects:	0	0.0	720.0
Head Markup:	646	17.7	168.0
Image URL Info:	675	0.0	24.0
Schema Indexes:	8	0.1	720.0
Shortened URLs:	0	0.0	2160.0
Video API Info:	0	0.0	24.0
All Transients:	1333	17.9

But, the actual records in the wp_options table:
Showing rows 0 – 49 (2664 total, Query took 0.0056 seconds.)
SELECT * FROM wp_options WHERE wp_options.option_name LIKE ‘%_wpsso_%’

and, this too keeps increasing.

You’re picking up the WordPress timeout values for transients, which are not transients – they’re the timeout (ie. expiration) values for the transients.

To select only WPSSO transients, you should use LIKE '_transient_wpsso_%'.

A query like WHERE option_name LIKE '%_wpsso_%' AND option_name NOT LIKE '_transient_wpsso_%' AND option_name NOT LIKE '_transient_timeout_wpsso_%' should not return much, if anything (there might be a few entries if you’re using the WPSSO RRSSB widgets or the WPSSO update manager).

js.

• This reply was modified 3 years, 5 months ago by JS Morisset. Reason: Fixing missing backticks

There are 1329 records for ‘_transient_wpsso_%’ and 1362 ‘%_transient_timeout_wpsso_%’ records and in the next 1 or 2 days the total count will run upto 50k+ and after that the web-host denies permission to write to the database.

Salman.

FYI – Note that 1333 transients (shown in the table you copy-pasted) is equal to 2666 entries in the options table since WordPress needs to keep track of the expiration time for each transient. The 1333 transients use 17.9 MB, which really isn’t much (the transients mostly contain meta tags and Schema markup), and the size of the expiration times should be negligible.

BTW, the “Image URL Info” transients should be a lot lower than that – WPSSO prefers to get images from the WordPress media library, but if it can’t, and must use a URL, then it gets the image information (width, height, mime type, etc.) for that URL and caches it. You may want to make sure the images you’re using are from your WordPress media library, and that they are large enough (should be at least 1200px in width and height to satisfy the requirements of all social and search sites).

js.

There are 1329 records for ‘_transient_wpsso_%’ and 1362 ‘%_transient_timeout_wpsso_%’ records and in the next 1 or 2 days the total count will run upto 50k+ and after that the web-host denies permission to write to the database.

The “Refresh Transient Cache” button creates cache entries for all posts, pages, users, and terms – the created cache entries should not increase much (if any) after that (404 pages and search results are not cached).

I can only think of one edge case that might create more cache entries – if your site creates post objects with an ID of 0, WPSSO will have to use the canonical URL to create a unique cache entry (since the ID cannot be used) – if the post ID is 0 *and* you have multiple canonical URLs pointing to the same post ID 0 content, then that would create different cache entries. But in practice this would not happen as there should be only a single canonical URL for each webpage, not different ones for the same webpage.

js.

BTW, are you using any WPSSO add-ons like the WPSSO RRSSB add-on? The WPSSO RRSSB add-on creates a transient cache entry for its buttons (one per post content). I may look at removing that feature since the WPSSO RRSSB buttons are created reasonably quickly, so a transient cache object provides only a very small performance improvement in this case.

js.

Count	MB	Hours
Form Selects:	0	0.0	720.0
Head Markup:	967	19.5	168.0
Image URL Info:	676	0.0	24.0
Schema Indexes:	8	0.1	720.0
Shortened URLs:	0	0.0	2160.0
Video API Info:	0	0.0	24.0
All Transients:	1656	19.7

This is the latest count and keeps growing. And, we are not using any add-ons only the WPSSO.

I was wondering if we can just disable the db transients? What would be the downside of doing that?

Those numbers are pretty low – we’re talking about a database here, not a spreadsheet or text file. ??

You can disable the head markup cache using the following filter, but I wouldn’t bother – it will make absolutely no difference to your database performance except having a handful fewer rows in your options table, but will slightly decrease performance in the back-end and front-end (unless you’re using a caching plugin).

add_filter( 'wpsso_cache_expire_head_markup', '__return_zero' );

js.

I am not worried about the 20mb or the even the 170mb+ getting created, I am more worried about the limits (150mb/table) imposed by the host. It makes the site unusable.

But, I will like to wait it out for a day or two and see what the size of the table is after that.

FYI – I’ve added a new “Cache Date Archive Pages” option in WPSSO Core v8.31.0-dev.2 to enable/disable cache for date based archive pages (disabled by default).

WPSSO does not refresh the date based archive pages in background (although maybe it should), so you’re probably seeing a few more transients being added as crawlers access those archive pages. This new option will effectively treat 404, search, and date based archive pages the same way (ie. no caching of meta tags and Schema markup).

js.