#61193 closed defect (bug) (fixed)
Prime transient and transient timeout options in `get_transient`
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.6 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Options, Meta APIs | Keywords: | has-patch has-unit-tests commit |
Focuses: | performance | Cc: |
Description
On sites without a persistent cache, temporary transients are stored in two options. One containing the transient itself, the other containing the timeout. These are stored as _transient_[transient name]
and _transient_timeout_[transient name]
.
Currently WordPress makes two database queries to get these options. With the introduction of wp_prime_option_caches()
in WordPress 6.4 it's now possible to reduce the querying of expiring transients to a single database request.
While a mild improvement on sites using a limited number of transients, I think it could become reasonably significant on sites running plugins that make heavy use of transients. WooCommerce being one example I can think of.
Follow up to #58962.
Change History (8)
This ticket was mentioned in PR #6540 on WordPress/wordpress-develop by @peterwilsoncc.
2 months ago
#1
- Keywords has-patch has-unit-tests added
@peterwilsoncc commented on PR #6540:
2 months ago
#3
Thanks @swissspidy. I decided overnight I should test for the specific queries that's the purpose of the change. I've pushed the changes to the test suite in eb8200a103467532a148d94a841e2eea5d248e74, the source remains unchanged.
#4
@
2 months ago
- Keywords commit added
- Milestone changed from Awaiting Review to 6.6
- Owner set to peterwilsoncc
- Status changed from new to assigned
The linked pull request has been approved so I am putting this on the milestone for inclusion in WordPress 6.6.
@peterwilsoncc commented on PR #6540:
2 months ago
#6
#7
@
2 months ago
@swissspidy I had a foolish moment and forgot about site transients.
For Multisite installs priming site transients will require #61053 be completed but for single site installs it's possible to prime the cache as they are stored in the options table. Do you think it's worth re-opening this to prime single site installs or better to wait for the other ticket to be completed?
In the linked pull request:
get
- andset_transient()
to verify the number of database calls is expectedget_option()
in bothget
- andset_transient()
.A broken test was pushed prior to each change to demonstrate the improvement.