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