mixed feelings

  • Using Chrome DevTools for precision, I measured the loading time when Redis Object Cache is on or off. I was surprised to find that when the plugin is deactivated, the site loaded faster. I’d say about 0.3 second or faster.

    Now when the plugin is completely deleted from the site, loading gets slightly faster. This baffled me.

    Thinking Redis itself is the problem, I deleted it from my Plesk-run server and loading time became much longer.

    So my conclusion is that it’s the plugin, not Redis that is slowing things down. I just have Redis running without the plugin now and it serves me better.

    I set wp-config.php properly with the salt_key and everything and confirmed Redis cache was running. Speed is so important to me so I made sure I had everything right.

    But I think the plugin is somewhat off at least for me. Maybe the pro version is better. But I decided not to use this any more because of my discoveries that it actually slows my site down. Even before I tested it with precision, I wasn’t able to tell the difference with my eyes, contrary to the many raves about this plugin. (One person told me it would do “wonders”. No it didn’t.)

    I hope I’m wrong and did something wrong, though I’m sure I didn’t. It’d be good to utilize this type of plugin for better speed.

    • This topic was modified 2 years, 10 months ago by creactivemind.
Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Till Krüss

    (@tillkruess)

    Could have asked for help, but why not leave a shitty review instead. Good job.

    Thread Starter creactivemind

    (@creactivemind)

    Well, as rude as your reply is, I think you have a point. So I’ve just edited the star rating to max.

    Much of my lack of success with getting this plugin to work may have to do with my lack of knowledge. So I’d like to ask you for help if you don’t mind.

    I set up my Redis on Docker in Plesk. It says it’s running so I see no issue with it.

    In WordPress, what I did was, I made sure my wp_config.php had the following

    define( ‘WP_CACHE’, true );
    define( ‘WP_CACHE_KEY_SALT’, ‘mydomain.com’ );

    Then I installed your plugin and activiated it. Here’s what I see in the settings.

    Status:	 Connected
Drop-in:	 Valid
Filesystem:	 Writeable
Key Prefix:	mydomain.com
Connection
Client:	PhpRedis (v5.3.5)
Host:	127.0.0.1
Port:	6379
Database:	0
Connection Timeout:	1s
Read Timeout:	1s
Redis Version:	6.2.6

    (above is what I see right after activating the plugin, so probably nothing cached. But the loading time did get a bit longer.)

    Is there something I’m doing wrong and not doing? Please bear with me as I’m no coder.

    Plugin Author Till Krüss

    (@tillkruess)

    First, the define( ‘WP_CACHE’, true ); is unrelated to object caching, that’s for the page cache.

    Other than that your diagnostics look good.

    So my conclusion is that it’s the plugin, not Redis that is slowing things down. I just have Redis running without the plugin now and it serves me better.

    If you don’t enable this plugin (and it’s drop-in), then Redis just sits idle and won’t be used.

    Next, measuring performance impacts with something like object caching is best done with an automated tool, because humans don’t perceive changes in milliseconds. Also, the first request after activating the cache, may take a bit longer, since it needs to warm up and do a bunch of writes.

    https://webpagetest.org allows you to run 9 runs, which will show you a more accurate performance picture.

    You could link the benchmark report here and I’ll take a look. If it’s still slower with Redis object caching enabled, post your full diagnostics and I’ll take a closer look.

    Thread Starter creactivemind

    (@creactivemind)

    thanks, I’m pretty confident Redis object cache is working. I checked it was running by using redis-cli monitor in SSH terminal. My Query Monitor also shows a hit rate of over 90% with the total number of database queries cut down by a third. (from about 330 to 200, although I’m not sure if that’s enough. I’ve copied and pasted the query monitor results below). With everything confirmed to be working, page loading still is slower with the object cache on than without, by about 0.5 second to 1 second. This is confirmed in webpagetest as well, using nine runs. My bare eyes can also feel it since I access these pages very very frequently.

    * my lightest page with the cache on:

    Page Generation Time
1.8370s
0.1% of 1,800s limit

Peak Memory Usage
85,442,544 bytes (81.5 MB)
4.0% of 2,048 MB server limit
4.0% of 2,048 MB WordPress limit

Database Queries
0.0492s

HTTP API Calls
0.0178s

Object Cache
93.0% hit rate (11,792 hits, 888 misses)

Persistent object cache plugin in use

Opcode Cache
Opcode cache in use: Zend OPcache
    Object Cache
Status
Connected

Hit Ratio
93%

Hits
11795

Misses
887

Size
7.88 MB

Global Groups
blog-details
blog-id-cache
blog-lookup
global-posts
networks
rss
sites
site-details
site-lookup
site-options
site-transient
users
useremail
userlogins
usermeta
user_meta
userslugs
redis-cache
blog_meta

    * my lightest page with the cache OFF:

    Page Generation Time
1.1870s
0.1% of 1,800s limit

Peak Memory Usage
94,613,304 bytes (90.2 MB)
4.4% of 2,048 MB server limit
4.4% of 2,048 MB WordPress limit

Database Queries
0.0772s

HTTP API Calls
None

Object Cache
Persistent object cache plugin not in use

The Redis object cache extension for PHP is installed but is not in use by WordPress. You should install a Redis plugin.

Opcode Cache
Opcode cache in use: Zend OPcache

    * my heaviest page with the cache on:

    Page Generation Time
2.6510s
0.1% of 1,800s limit

Peak Memory Usage
101,029,304 bytes (96.3 MB)
4.7% of 2,048 MB server limit
4.7% of 2,048 MB WordPress limit

Database Queries
0.0519s

HTTP API Calls
None

Object Cache
96.3% hit rate (24,046 hits, 917 misses)

Persistent object cache plugin in use

Opcode Cache
Opcode cache in use: Zend OPcache
    Status
Connected

Hit Ratio
96.3%

Hits
24046

Misses
917

Size
9.93 MB

Global Groups
blog-details
blog-id-cache
blog-lookup
global-posts
networks
rss
sites
site-details
site-lookup
site-options
site-transient
users
useremail
userlogins
usermeta
user_meta
userslugs
redis-cache
blog_meta
Non-persistent Groups
counts
plugins
themes
Metadata
Client	PhpRedis (v5.3.5)
Redis Version	6.2.6

    * my heaviest page with the cache OFF:

    Page Generation Time
2.1662s
0.1% of 1,800s limit

Peak Memory Usage
116,432,680 bytes (111.0 MB)
5.4% of 2,048 MB server limit
5.4% of 2,048 MB WordPress limit

Database Queries
0.0728s

HTTP API Calls
None

Object Cache
Persistent object cache plugin not in use

The Redis object cache extension for PHP is installed but is not in use by WordPress. You should install a Redis plugin.

Opcode Cache
Opcode cache in use: Zend OPcache

    I truly hope this cache will work and I can also reap the benefit of Redis object cache. It baffles me that with the number of database queries cut, the page loads slower. Could this be due to some conflict with another type of cache, such as Opcode? By the way WP Rocket is turned off during these tests. Any thoughts would be nice. Thanks.

    • This reply was modified 2 years, 10 months ago by creactivemind.
    Thread Starter creactivemind

    (@creactivemind)

    Care to comment?

    Plugin Author Till Krüss

    (@tillkruess)

    These numbers are interesting.

    11,792 hits and 24,046 hits is a lot, so is 9.93 MB of cache data. Cache hit rates below 98% are not great.

    Looks like you got a massive site and if you run a business I’d strongly suggest Object Cache Pro.

    My guess is either your Redis Server is busy writing cache keys, or just can’t answer thousands of commands per request.

    Do you happen to have the analytics enable and can share the “Calls” numbers?

    A dump of redis-cli info after running your tests would be helpful too.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘mixed feelings’ is closed to new replies.