[wp-trac] [WordPress Trac] #33276: redundant wp_using_ext_object_cache check in get/set_transient

[WordPress Trac]

#33276: redundant wp_using_ext_object_cache check in get/set_transient
--------------------------+------------------------------
 Reporter:  shmulikk      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Cache API     |     Version:  2.8
 Severity:  normal        |  Resolution:
 Keywords:  2nd-opinion   |     Focuses:  performance
--------------------------+------------------------------

Comment (by shmulikk):

 Hi,
 Thank you for the quick and detailed feedback.

 Basically once an external cache plugin misbehave - the transients
 functionality breaks, causing any feature dependent on transients to fail.
 In my experience one core feature breaks - the wp_cron
 (https://codex.wordpress.org/Function_Reference/wp_cron) which results
 with cron runs with every request instead of once per interval (default
 once per 60 seconds).
 I think this solely is a good cause to have more fault tolerance
 transients.
 On top of that also couple other plugins we use are breaking too as they
 never manage to persist data between requests using transients.

 Now there are two roads to take IMO:
 1. Assume any third party caching plugin must fallback to the DB for
 persistent caching.
 2. Make the transients functionality to behave as it usually does,
 ignoring any external caching plugin existance in it's logic.

 If we remove this logic to look for external 3rd party caching plugins in
 the core, we gain:
 1. WP functionality is working as expected even while persistent caching
 doesn't.
 2. Removing short-circuiting, which in case the 3rd party works - behave
 just about the same. Except of the valid point by @johnbillion - that the
 cache group will shift from 'transient' to 'options'.

 The thing is that my suggestion is not a new behavior. This fallback from
 'transient' cache group to 'options' happens anyway in the current code
 set of WP core. My only suggestion is to always use it, even while 3rd
 party caching plugins are in place.
 Once we always use it - we enable all the stability / robustness we need,
 which is already there.

 Regarding tests - I've created a while ago [https://github.com/jmeter-
 templates/wordpress an open source framework to performance test WP]. This
 is a subset of what I'm using to test the stability and performance of our
 own system, in addition to hugh set of cucumber (functional) tests we are
 running for our own customizations / plugins, which also go through core
 functionality.


 Maybe I'm missing the point of this short-circuit, but I cannot understand
 why having it in the first place.

 Regarding diffs - I'll attach later today, just so this ticket will be
 more detailed.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33276#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform