Lots of autoloaded data

What do you mean by autoloaded data? Autoloader options? Transients should not be autoloaded. Those remote request transients are needed to perform the server-side rendering, to inline the ampshared.css. Nevertheless, such transients queries should be very fast.

Are there other AMP transients in the wp_options table that are taking up many rows?

Note that redux_builder_amp is not coming from this AMP plugin.

Autoloaded data – rows in wp_options that have the autoload column set to yes. Certain information in the database must load on each request, such as the site’s URL and active theme and plugins. We have 6 of this ‘_transient_amp_remote_request_*` in our site and wondering if we can only have one instead? Because it is adding up to our site’s autoloaded data in which turns our TTFB slow.

Screenshot
https://ibb.co/9hJmHqf

Humm, I’m seeing that too:

> SELECT option_name FROM wp_options WHERE autoload = 'yes' AND option_name LIKE '_transient_%';
+----------------------------------------------------------------+
| option_name                                                    |
+----------------------------------------------------------------+
| _transient_amp_remote_request_9ecf31f5a69c5a093c36f509d7e0f9ac |
| _transient_amp_remote_request_45d702de4499a0a5e245d2b8e196e05b |
| _transient_amp_remote_request_87dae8a975ce1e4a887293f39ffefa0d |
| _transient_amp_remote_request_c23cd6d3f67e8500044f607f51460d6e |
| _transient_amp_remote_request_ffafd018a2dd6d0b6909cbe596a9b480 |
| _transient_amp_remote_request_ffe55ba87e5ebdd6e5beac24d985a79f |
| _transient_amp_remote_request_81429d626fe0e2e142575ad511e4b48e |
| _transient_amp_remote_request_dfbd4065bb6f487054a82186932d719e |
| _transient_amp_remote_request_3ed83d8ebf4f720c21cc060d3a664d8f |
| _transient_amp_remote_request_101623f47561580a914e5d56e153cf6c |
| _transient_amp_remote_request_8c2c8724a0393a596972c2d34a593e3a |
| _transient_amp_remote_request_5602bb6bb0292910f56ad18ec5da3131 |
| _transient_amp_remote_request_8cfa715f2eb2cf6eca71f053d26e40bc |
| _transient_amp_remote_request_fdc758809af1aadfe3fd7a267799e99e |
| _transient_amp_remote_request_cdb3965b692fa1c6552beb3aaa054585 |
| _transient_amp_remote_request_82b322783f526b6f615ef9aa3a50d65b |
| _transient_amp_remote_request_8ee204c8fe954cfe61d52b7c4bf4afd2 |
| _transient_amp_remote_request_c6cede26fc97684a9c573574ffe49062 |
| _transient_amp_remote_request_d754e3df320fa9210159803b282aa720 |
| _transient_health-check-site-status-result                     |
| _transient_amp_remote_request_1f77efde5883ed378a3a0077757fc5ab |
+----------------------------------------------------------------+

There are 20 such autoloaded options for me. How many are there for you?

This is where it is coming from: https://github.com/ampproject/amp-wp/blob/19f6fb6bbf59a5bba3884bffe81a0e317bb638f5/src/RemoteRequest/CachedRemoteGetRequest.php#L138

The cause is that there is no $expiration being set. I wasn’t aware that WordPress added transients without expiration to be autoloaded:

https://github.com/WordPress/wordpress-develop/blob/af9db19b45737deaae5dfe2e0175eab1ac732450/src/wp-includes/option.php#L881-L886

I only have 6 amp related expired transients in the site. Is it safe to removed amp transients? or should I wait for the next update for the fix?

I’m discussing with the team. In the meantime, I suggest updating those transients to be autoload = 'no'. If you delete them, the AMP plugin will re-create them since they are needed to generate AMP pages.

Nevertheless, is this really a cause for slowing down the TTFB? I find it incredible that 6 additional autoloaded options would slow down your site by any perceptible way.

We have other autoloaded data on the site that all add up that affects the site performance. I’m currently trying to remove unnecessary data to keep our autoloaded data below 800,000 bytes. A recommendation by WPEngine – https://wpengine.com/support/database-optimization-best-practices/#Autoloaded_Data

I assume they’re making this recommendation because they assume you’re using a persistent object cache. However, if you are getting these transients stored in wp_options then that means you don’t have object caching enabled.

If you want to really speed up your TTFB, you should enable object caching: https://wpengine.com/support/wp-engines-object-caching/#Enable_Object_Cache

I just check within WPEngine and object caching is indeed disabled. Thank you! I’ll definitely enable this once we have reduced the autoloaded size on our site. Autoloaded data is still connected in the object caching though.

If the content that’s autoloaded surpasses the amount Object Caching can handle, then it rejects the request. WordPress, requiring the autoloaded data, sends the request again, and this causes a loop that eventually ends in a 502 error on the site.

The object cache size buffer is 1Mb.

https://wpengine.com/support/wp-engines-object-caching/#Object_Cache_and_502_Errors

• This reply was modified 4 years, 5 months ago by Danilo Parra Jr..

Actually, if you delete all transients and then enable the persistent object cache, then you see that the transients no longer get stored in the wp_options table at all. They instead get stored in the object cache and do you won’t have any problem with transients causing the autoloaded total to go over 1MB. When a persistent object cache is enabled, there is no such thing as an autoloaded transient.

Thank you, Weston. I’m currently testing this in our staging site. If ever I have issues with the transients, I’ll let you know.

We also have a PR open to prevent such transients from being autoloaded: https://github.com/ampproject/amp-wp/pull/5476

But again, by switching to a persistent object cache then this issue should be a thing of the past for you.