WP Updates for own plugin: site_transient_plugin in a long loop

To be clear, I found that some caches will invalidate transients much before their intended timeout.

I do store my API calls in the options table of the database, but I also include an expiration on the data.

Before making an attempt to query the API for the data I check to see if that data exists and is not expired. If the API doesn’t need to be queried then I quickly exit.

The primary difference between the 2 filters pre_set_site_transient_update_plugins and site_transient_update_plugins is that the first fires on set_site_transient() where the second fires on get_site_transient(). In this case I found more consistent results by using the second function.

It’s really whether or not the code is being called more frequently it’s how it reacts if it has unexpired data and doesn’t need to make the wp_remote_get() call.

All your log really shows is that you call get_site_transient() a lot. ??

Put a timer on your code if you really want to see how efficient it is.

• This reply was modified 3 years ago by Andy Fragen.

@afragen storing in the options tables looks a great idea.

You have a huge control over your API calls which makes a lot of sense optimization-wise.

Following your comment, I’ve been debugging get_site_transient, as like you mention it’s being called constantly

I’ve tested this scenario:

Created just a little plugin, that simply asks for updates with the update method commented above with site_transient_update_plugins

Disabled ALL the plugins in the site (a total of 30) except this one:

View post on imgur.com

Run the update page and same happens: tons of calls to get_site_transient

Something says to me that this is the common behaviour of site_transient_update_plugins

This is the snippet that does this job:
https://pastecode.io/s/5hpyfeuy

Maybe I’m doing something wrong, which is unlikely (or maybe i’m missing to set something critical in the transient array to avoid this constant checking behaviour!)

You’re actually making a wp_remote_get() call each time get_site_transient() is run. This is very expensive and why I store the result and check before make the call again.

If you simply want me I see how many times set_site_transient() or get_site_transient() is called, just make a time notation using error_log() and check your debug.log

Again, it’s not necessarily the number of times your code runs if it exits early when it doesn’t need to make expensive API calls.

• This reply was modified 3 years ago by Andy Fragen.

@afragen

Again, it’s not necessarily the number of times your code runs if it exits early when it doesn’t need to make expensive API calls.

Yes, this is what I did: I set an error_log in get_site_transient to observe, that is being called 50 or 60 times.

From what I’m observing, site_transient_update_plugins simply calls get_site_transient when you have a ton of plugins installed (like in my case 31 plugins in total).

Tomorrow I’m going to test in a new clean WP environment with just 2 o 3 plugins installed, to see how many times get_site_transient is called, and see if my theory that the more amount of plugins the more calls is true.

I see your point of skipping earlier (which I’m not doing), but I would like something that is by default in WP. Basically if I do what you suggest:

1. Check if the API call is stored and not expired, if yes, exit the function
2. If not do the api call
3. Store the info with a timestamp

In this scenario, get_site_transient might be called 50 times, but since it will be exiting all the time, it should technically have no impact over the performance (despite being called 50 times!).

But my big question here is: how can I avoid those 50 calls at all? (or reduce them to just 1 or 2).

Maybe there is a parameter in the transient array that does exactly this

I wrote a little plugin to count the number of times these 2 filters are called and the cumulative time it takes to run all those calls.

The plugin is here, https://gist.github.com/afragen/a8a89888c60c4836a21667531469c7a9

The data is as follows.

[11-Mar-2022 02:12:42 UTC] index.php:pre_set_site_transient_update_plugins: 2 calls - 0.000007 seconds (cumulative time)
[11-Mar-2022 02:12:42 UTC] index.php:site_transient_update_plugins: 6 calls - 0.000015 seconds (cumulative time)
[11-Mar-2022 02:12:52 UTC] update-core.php:pre_set_site_transient_update_plugins: 4 calls - 0.000017 seconds (cumulative time)
[11-Mar-2022 02:12:52 UTC] update-core.php:site_transient_update_plugins: 11 calls - 0.000031 seconds (cumulative time)
[11-Mar-2022 02:13:09 UTC] plugins.php:pre_set_site_transient_update_plugins: 4 calls - 0.000015 seconds (cumulative time)
[11-Mar-2022 02:13:09 UTC] plugins.php:site_transient_update_plugins: 57 calls - 0.000126 seconds (cumulative time)
[11-Mar-2022 02:13:35 UTC] plugins.php:pre_set_site_transient_update_plugins: 4 calls - 0.000017 seconds (cumulative time)
[11-Mar-2022 02:13:35 UTC] plugins.php:site_transient_update_plugins: 6 calls - 0.000015 seconds (cumulative time)

As you can see even 57 calls from a single page has a negligible time when a quick exit is done.

Version calling the pre_set_site_transient

[11-Mar-2022 13:47:20 UTC] plugins.php:pre_set_site_transient_update_plugins: 4 calls – 0.000011 seconds (cumulative time)
[11-Mar-2022 13:47:20 UTC] plugins.php:site_transient_update_plugins: 44 calls – 0.000084 seconds (cumulative time)

Version with site_transient

[11-Mar-2022 13:51:04 UTC] plugins.php:pre_set_site_transient_update_plugins: 4 calls – 0.000009 seconds (cumulative time)
[11-Mar-2022 13:51:04 UTC] plugins.php:site_transient_update_plugins: 44 calls – 0.000096 seconds (cumulative time)

Very strange: both are almost the same, but the time it takes to reload, is like 5 times less if not more with pre_set_site_transient

But if I set the log in set_site_transient, and I count the number of calls manually I can identify that the number of calls is the same. But the number of calls to my function is only twice with pre_set_site_transient and with site_transient is 40.

Conclusion: set_site_transient function is not the issue that hinders the speed. Not all set_site_transient calls, call my function, so I can’t find any correlation.

EDIT:

I’ve noticed that there is $pre condition in the get_site_transient, which lets you, by using pre_set_site_transient_ skip all the extra checkings.

I think is a bad idea for this scenario using site_transient_as you suggest. If you have some logic to always query the database for store API info with a timeout, you could simply apply this same logic to simply return a true $pre and skip the whole set_transient.

Now I think I have a better understanding of all this update transients. Still I’m not sure what is exactly calling my function, I will do a callback trace later.

• This reply was modified 3 years ago by SirLouen. Reason: Extra info