Page Timeout

for me it has been good for a few days now. It has never looked this good for that long.
Before perfo was really bad

First of all I want to start with a really big THANK YOU to @domainsupport for the effort, the depth of investigations and the patience.

I’m also experiencing this issues from many time ago and I haven’t found yet any object cache plugin for WordPress which works really as expected. In my case I have a setup with a DB very similar in size as yours, with around 20.000 entries and a table for metas that it’s also large.

The page rendering in backend (it’s apache managed with a nginx reverse proxy on front) it’s sometimes really slow, with times that often reach 10 or even 20 seconds.

As you have perfectly described it’s solved deactivating the object cache plugin and activating it again. I’ve tried with both phpredis and relay (haven’t tried with predis, cause I believe I’ve not installed on my server, but may be I’m wrong and the plugin uses it without advertising).

To be sure, I’ve also replicated a test server with object cache pro on it, and it happens exactly the same.

Finally I will keep an eye on this thread looking for any news about the issue. If I can give more details I’ll do.

kind regards, and thanks again

@fidoboy There is definitely a problem. Whether it’s with Redis itself or with this plugin, I don’t know but here is my evidence …

1. 5 days ago I turned Redis back on and page requests are nice and fast
2. Today I look at the site and page requests are taking several seconds
3. I rename /wp-content/object-cache.php to object-cache-off.php, load a page without the cache then rename back to object-cache.php
4. Page requests are fast again. No flush has been enacted and this happens with both Predis and PhpRedis.

We have three sites running Redis, each one is on its own Ubuntu VPS server that has plenty of RAM and multiple CPUs and interestingly one of them suffers much more with this issue than the others but they all suffer.

I’m just glad I’m not the only one who has this issue.

After some trial and error I’ve noticed that even when the notoptions key exists, monitoring the Redis operations you’ll notice that there are many failed queries with non existant keys.

I’ve verified it with:

wp cache get notoptions options

and then observed that keys that are present into the notoptions key are already being requested with each new page operation in WordPress. This lowers a lot the hit ratio for the Redis object cache.

• This reply was modified 11 months, 3 weeks ago by fidoboy.
• This reply was modified 11 months, 3 weeks ago by fidoboy.

I don’t know for sure if this is the expected or desirable behaviour, but when I inspect the database created by the Redis object cache plugin I can see a hash for the alloptions but there is none for the notoptions.

• This reply was modified 11 months, 3 weeks ago by fidoboy.

@domainsupport I am getting my first Redis timeout again after 3 to 4 weeks. So this is a bummer for me ??

I need to flush the object cache?

edit: perhaps this topic doesn’t need to be marked as “resolved” :)?

• This reply was modified 11 months, 2 weeks ago by dyin.
• This reply was modified 11 months, 2 weeks ago by dyin.

@dyin I’m really sorry but the only solution (temporary) that we found was to rename object-cache.php load a page without it and then put it back again.

We could probably automate that process but I actually found our sites to perform better without Redis so we’ve given up and uninstalled it.

Unfortunately the plug-in author doesn’t recognise that there is an issue here which is why they marked the issue as resolved.

Sorry if that’s not what you want to hear ??

@domainsupport thank you for your super fast reply. I will also consider removing it next summer. I don’t understand why on this plugin issues are always marked as resolved. On other plugin support pages they don’t do that

@dyin I am also a plugin author and I don’t mark support topics as resolved until they are actually confirmed resolved by the user. Not all plugin authors do the same unfortunately.

For me the fix was to rename the object-cache.php file, log to my vps with ssh, flushall the data from redis -> restart redis (just in case) -> rename the object-cache.php back to original and everything works.

I need to do this every 3-4 months as it seems. Or when my Redis DB reaches 4m lines.

@herculesasl Yes, that was the fix for us too only it needed to be done every week which we weren’t happy to do. We are currently testing Memcached on one of the servers and so long as that continues to go well we will be rolling it out to our other sites.

@domainsupport

The only problem with that is that i heard thar Redis is better from Memcached for some reason… is it true ?

I’ve no idea … but we’ve had Memcached running on the server we’re testing it on for nearly three weeks and it hasn’t made the site crash which wasn’t the case with Redis. There’s also a great PHP control panel to monitor memory usage (amongst other things) incase you need to increase the default from 64Mb.

So far we’re happy with it ??

That seems great, i will try it on another machine ! Thank you

Let me know how you get on. I have another site with 300,000+ visitors per month that I’m holding off installing it on until I’m 100% sure it’ll work OK! ??