Page Timeout

We have installed WP Redis. It identified that it required the PHPRedis extension which we have installed. Is this not required for your plugin? Would not having it cause the issues described?

Both Predis and PhpRedis would encounter the same read error on connection error coming from Redis Server.

It’s now been 11 days with WP Redis (which uses PHPRedis instead of Predis) running on https://hofnar.com and there has not even been a sign of any kind of slow page load let alone any timeouts.

So I’m afraid it looks like there may well be an issue with your plugin (as I suspected) rather than an issue with the Redis server.

Obviously I will update this topic again if there is a change.

No, WP Redis just silently discards any Redis failures, so you won’t know when WordPress is connected to Redis and when not.

This is fine 90% of the time, but the other 10% will cause your cache to go out of sync and if you search the forums, you’ll see that the results of that are catastrophic, especially on e-commerce sites.

https://github.com/pantheon-systems/wp-redis/blob/d8eb080c7f113d73e7df54f814981ce1dacacd1c/object-cache.php#L1476

This does not explain why your plug-in renders our websites unresponsive and times out whereas WP Redis renders the page requests (so far) extremely quickly without any delay.

I will obviously update this topic if that changes.

I think it may be prudent to explore the possibility that there may be an issue.

No, it does exactly explain that.

We are not seeing any Redis failures. And if there were Redis failures then the site would be unresponsive as is the case when your plug-in is used for any length of time.

Please note that the silencing of errors would not prevent the page requests timeouts that we see with your plug-in.

So far we do not see page requests timeouts (or any delay in page load) with WP Redis.

https://en.wikipedia.org/wiki/Dunning–Kruger_effect

That’s pretty insulting.

I hope you apologise if an issue presents itself.

I’m very good at tracking down the cause of issues like this.

I’ve explained what happening in detail, but you don’t accept my answer and insist you’re correct. Sounds like Dunning–Kruger to me ???♂?

How about this: I’ll pay you US$5000 if you can prove that I am wrong and open a PR with the fix.

OK then LOL.

Let’s start by seeing if there are any exceptions at all being ignored by WP Redis … if there are then I’ll concede this is a shared issue (albeit still an issue) …

	protected function _exception_handler( $exception ) {
		try {
			$this->last_triggered_error = 'WP Redis: ' . $exception->getMessage();
			// Be friendly to developers debugging production servers by triggering an error.

			// phpcs:ignore WordPress.PHP.DevelopmentFunctions.error_log_trigger_error,WordPress.Security.EscapeOutput.OutputNotEscaped
			error_log( $this->last_triggered_error );
		} catch ( PHPUnit_Framework_Error_Warning $e ) { // phpcs:ignore Generic.CodeAnalysis.EmptyStatement.DetectedCatch
			// PHPUnit throws an Exception when trigger_error() is called. To ensure our tests (which expect Exceptions to be caught) continue to run, we catch the PHPUnit exception and inspect the RedisException message.
error_log( 'WP Redis Caught: ' . $exception->getMessage() );
		}
	}

As I suspected, after 36 hours debug.log is still empty. This debunks your explanation.

On examination of your object-cache.php, I can see that we are able to define WP_REDIS_CLIENT to be phpredis so I have done this and re-enabled your plugin in place of WP Redis …

Connection

Client:PhpRedis (v5.1.1)
Host:127.0.0.1
Port:6379
Database:0
Connection Timeout:1s?
Read Timeout:1s?
Retry Interval:0ms?
Redis Version:5.0.7

If after a couple of weeks we do not see slow page loads or timeouts then I suggest the issue is caused by Predis itself. If on the other hand we do see slow page loads or timeouts then the issue is likely to be something to do with your plugin itself.

I have further tests planned for either scenario.

So I have an update. I have discovered that the read error on connection and page timeouts are not related. They are two separate issues which I will attempt to explain …

The page timeout / slow response is 100% related to using Predis rather than PHP Redis. After over two weeks of using https://hofnar.com with your plugin and PHP Redis (rather than Predis) we have had no page load issues at all and the site continues to load very quickly. We have also had no error notices in debug.log. This leads me to believe that there is an issue in the way that Predis connects to Redis that does not present itself when PHP Redis is used instead. I would suggest that it may be worth setting your plugin to see if PHP Redis is available and if so use that as a default Redis connection rather than Predis. If you would like to undertake further testing to find out exactly what is causing the timeout when Predis is used, please let me know.

Now on to the cause of the read error on connection notices which I can replicate by flushing the Redis cache or by disabling Redis using “Flush Cache” and “Disable Object Cache” buttons on your plugin’s settings page. Please note that this can be replicated when Predis or PHP Redis is being used.

This is caused because you are firing both actions on the load-settings_page_redis-cache hook and when there is a large amount of cache data to flush this process takes longer on the Redis server than the rest of the page takes to load. This means that subsequent Redis requests on the same page load are not successful and a read error on connection is resultant.

The fix for this would be to defer the flush-cache and disable-cache actions to the shutdown hook. This would prevent cache requests from the current page load from failing and presenting the read error on connection errors.

I have attempted to create a PR but you need to add me as a collaborator …

Pull request creation failed. Validation failed: must be a collaborator

My account on GitHub is webd-uk

Thank you,

Oliver

I would suggest that it may be worth setting your plugin to see if PHP Redis is available and if so use that as a default Redis connection rather than Predis.

This is a great suggestion and I double checked, that’s already happening. I’ve updated the docs.

Now on to the cause of the read error on connection notices which I can replicate by flushing the Redis cache or by disabling Redis using “Flush Cache” and “Disable Object Cache” buttons on your plugin’s settings page. Please note that this can be replicated when Predis or PHP Redis is being used.

Would you mind elaborating more on how I can replicate this? In what order do you press the buttons? Do you wait until the cache was flushed, the page reloaded and then disable it? Do you click both quickly right after another?