Wordpress Using: Redis as a front-end cacher instead of using a caching plugin - MUCH faster

For the last several hours, I've been working with Redis as a front-end cacher for WordPress. Within my own testing, Using it this way works VERY well. Putting up 2 blogs, exact same theme, plugins - one has Redis and the other had WP Super Cache. Redis was faster by about 100+ms in page loading on each test. PageSpeed was not effected by it and still continued to work well with it. However, using a CDN was affected by it so I had to rename the upload path to /wp-content/uploads/ to my CDN URL to the images would at least load on the CDN. PageSpeed can handle the CSS and JS which I like it better that way anyway.

I installed Redis from source:

Code:

mkdir /tmp/redis
cd /tmp/redis
wget http://download.redis.io/releases/redis-3.0.0.tar.gz
tar xzf redis-*
cd redis-*

Next step is to compile with make utility and install:

Code:

make
make install clean

Create config:

Code:

mkdir /etc/redis
cp redis.conf /etc/redis/redis.conf

By default redis-server will install in /usr/local/bin/redis-server. Check it whith whereis command:

Code:

whereis redis-server
#redis-server: /usr/local/bin/redis-server

Start server

Code:

redis-server /etc/redis/redis.conf 

After the install, I followed these instructions:

Once everything was installed and working, I uninstalled the caching plugin and looked in the corner of my WP site to see if the cache was working and it was!

---

It works and works well. Reminds me allot of Varnish which this is a good substitute for Varnish.

 

I knew about the Redis 2.8 and I did install the 2.8 on a few VPS's but when I came across the 3.0.0, I was like hmmmm lol!

I always like to run Siege that comes with Centmin Mod to do a preliminary load test. All those other tests like blitz.io are so expensive but I don't know how reliable Siege really is but I did a few test on my VPS's with Resis Front-End Cache...

using: siege -c100 -d10 -t3M

Code:

Transactions:                   3459 hits
Availability:                 100.00 %
Elapsed time:                 179.36 secs
Data transferred:              49.51 MB
Response time:                  0.03 secs
Transaction rate:              19.29 trans/sec
Throughput:                     0.28 MB/sec
Concurrency:                    0.54
Successful transactions:        3459
Failed transactions:               0
Longest transaction:            0.19
Shortest transaction:           0.01

Using: siege -c500 -d10 -t3M

Code:

Transactions:                  17622 hits
Availability:                 100.00 %
Elapsed time:                 179.41 secs
Data transferred:             252.22 MB
Response time:                  0.05 secs
Transaction rate:              98.22 trans/sec
Throughput:                     1.41 MB/sec
Concurrency:                    5.28
Successful transactions:       17622
Failed transactions:               0
Longest transaction:            0.73
Shortest transaction:           0.01

Using: siege -b -t600S

Code:

Transactions:                  83401 hits
Availability:                 100.00 %
Elapsed time:                 599.32 secs
Data transferred:            1193.69 MB
Response time:                  0.11 secs
Transaction rate:             139.16 trans/sec
Throughput:                     1.99 MB/sec
Concurrency:                   14.97
Successful transactions:       83401
Failed transactions:               0
Longest transaction:            5.16
Shortest transaction:           0.04

If these are accurate tests, then that's pretty good for a OpenVZ Container considering their configuration limitation compared to XEN or KVM