Consider alternative to using object-cache drop-in to implement early Server-Timing

[westonruter]

The use of the object-cache drop-in Server-Timing is clever but also clearly a hack. Ideally we wouldn't need to use this. I recall users reporting issues with the approach, for example today.

What would we lose if we didn't the Server-Timing API wasn't available before plugins_loaded?

As opposed to object-cache.php could the plugin install an mu-plugin instead?

[b1ink0]

What would we lose if we didn't the Server-Timing API wasn't available before plugins_loaded?

The first thing we would miss is the object cache load itself. Additionally, we would not be able to measure everything that happens in wp-settings.php between wp-settings.php#L147 and wp-settings.php#L492 This means we wouldn't be able to measure most of the core load if we switched to the mu-plugin approach. However, if measuring this is not a priority, then moving to the mu-plugin approach would be a viable option.

[westonruter]

Nevertheless, what would be missed?

In looking at perflab_register_default_server_timing_before_template_metrics() it's already using $GLOBALS['timestart'] to obtain the start of the process, so does it really matter when we load? The only thing we could miss out on is whether there could be logic in object-cache.php or in wp-settings.php which would be attempting to add new Server-Timing headers, right? This seems very unlikely.

[b1ink0]

In looking at perflab_register_default_server_timing_before_template_metrics() it's already using $GLOBALS['timestart'] to obtain the start of the process, so does it really matter when we load?

I agree, it is already using $GLOBALS['timestart'] to obtain the process start time. Since this is set in wp-includes/load.php, which is loaded early in wp-settings.php, we should get correct measurement.

Does this issue require further discussion, or can I start working on it?

[westonruter]

Let's get @felixarntz's thoughts.

[felixarntz]

Additionally, we would not be able to measure everything that happens in wp-settings.php between wp-settings.php#L147 and wp-settings.php#L492 This means we wouldn't be able to measure most of the core load if we switched to the mu-plugin approach.

This is basically why the object-cache.php hack exists. There are currently no metrics built-in that need this, but that doesn't mean it's not relevant. When the Server-Timing integration was first implemented, we were actually using this to measure the time it takes to load all the autoloaded WordPress options, which is something that more or less always happens before a plugin or MU plugin could trigger.

I think it's fair to think about and discuss whether it makes sense to maintain this hack in regards to the benefits it brings. I'm slightly leaning to maintaining it unless/until there are real problems with it, but I don't feel strongly about it. Curious to discuss further.

I don't think it would make sense to replace the mechanism with something like an MU plugin though. That's much too late for what this is supposed to do and barely better than a regular plugin. And anything else (another drop-in) would be similarly a hack. So I think the discussion should be about whether to have or not to have this, but not about whether to replace it with something else (unless I am critically missing a better opportunity to do this!).

[westonruter]

Another support topic about this causing issues: https://wordpress.org/support/topic/object-cache-php-conflict-with-redis-object-cache/

[felixarntz]

Hmm looks like the issue is that the presence of our drop-in will cause other plugins that actually need the drop-in to bail when they see the file - which makes sense. The order of operation matters here, because if they installed the object cache plugin first and then Performance Lab, our plugin would place its drop-in in a way that both plugin's drop-ins behaviors remain active. But of course that doesn't work if our drop-in gets placed first and the other plugins don't act in the same way.

Here's an idea: How about we revert the opt-out mechanism to become an opt-in mechanism? That way we don't get rid of any functionality, but we significantly avoid the chance of problems. Those that want to use the drop-in can do so, but those that don't care won't get any conflicts.

[westonruter]

@felixarntz Yes, that sounds great. I was going to suggest that we switch to an opt-in approach, but then I hesitated because it sounded like you needed it to be enabled by default for the sake of gathering metrics for autoloaded options? But I suppose since that effort is largely wrapped up then it can be moved back to an opt-in approach?

[felixarntz]

Exactly. Let's do that.

[westonruter]

The question then remains how to do the opt-in and also about migrating from the previous opt-out to the opt-in state.

Would the opt-in consist of defining a new PERFLAB_ENABLE_OBJECT_CACHE_DROPIN constant in wp-config.php which would cause the object-cache.php to be installed in perflab_maybe_set_object_cache_dropin()?

For existing sites that already have the drop-in installed but haven't defined PERFLAB_ENABLE_OBJECT_CACHE_DROPIN, I suppose they would continue to work as before. It's just PL wouldn't try to install the drop-in in perflab_maybe_set_object_cache_dropin() since PERFLAB_OBJECT_CACHE_DROPIN_VERSION would be defined.