24 comments

[ 3.0 ms ] story [ 71.0 ms ] thread
A gist of the entire Predis library on the blog post? That's a bit… inefficient… to say the least.
if you're technical enough to set up Redis I'd think you're technical enough to ditch Wordpress silliness and just publish statically.
But you might run the blog with someone who isn't. Or be running the blog for someone else. Setting up varnish is another option that's likely even better (didn't read the details of the post, but it looks like it always hits a php script to get the cache).
I think integrating wordpress-like administration systems with static publishing systems should be a major goal. That's how movable-type used to work in the old days, and it was great. Now that we have client-side plugins like Disqus for dynamic interactivity features, there's no need for published content to be dynamically rendered. It's all downside and no upside, other than, "wordpress exists".
Setting up redis very simple. Ditching WP isn't.
I found ditching WP very simple, and unlike adding redis, you can even ditch your host and stick your files on S3. My quality of life improved dramatically once I didn't have to keep patching wordpress, breaking all my plugins every 6 weeks, and still getting hacked once in awhile anyway.
You could do exactly the same with nginx or Varnish acting as reverse caching proxies. Cool hack, but nothing I would ever run in production when you have all the other good tools at your disposal. Tools that are proven and that actually scale.
Yep, here, Redis is an unnecessary component, since he is caching the entire HTML page it seems, in Redis.

Seems he can accomplish the same with Nginx itself (which he's already using -- though not certain of the details if u are serving PHP via nginx itself too).

There is a place for a Memcached/Redis type role in generating a Wordpress page. Tools like W3 Total cache store certain small elements of the page in Memecached. So, could see Redis being used there. But for blind full page caching, Nginx can do that job.

Yep, and as bonus you get proper cache invalidation, ESI-support and a lot of other really nice features that you probably need when you start having these kinds of issues. Around 30 lines of VCL would replace all of this and make it even faster.
And memcached is not even the best option, using apc with W3 is few times faster than using memcached.
You are talking about two different things here. Memcached is a memory store, while APC is a opcode cacher. W3 seems to be a plugin for Wordpress that serves pre-rendered pages using some mod_rewrite trickery.
(comment deleted)
Redis doesn't actually provide much here. Use nginx caching directly. That gives you all the nginx cache handling goodies. Then, if its really necessary (probably not) you can put the cache directory into mem with TMPFS.
> I have been working with professionally on the web for over 7 years and have not once been able to configure Memcached properly.

What were the problems you had with Memcached? Assuming you install it from your distro's respositories, you just need to tweak a configuration file with less than 10 options, the most important option being -m. Unlike Redis, Memcached rarely adds exciting new features, so there's little incentive to compile it yourself.

Apparently he hasn't been working very professionally, it's an incredibly easy service to run. I still have the same version of memcached running from 2008.
One thing here I found surprising is the claim that Redis is easier to install than memcached.

Ubuntu or Debian: apt-get install memcached

OS X: brew install memcached

CentOS/Fedora: yum install memcached

They're both essentially one command to install on popular platforms, and both have extremely simple conf files.

I'm sorry but I cannot take this article seriously. Memcached is trivial to install and to set up on all the Linux distributions that I know of. On Ubuntu, it's actually as simple as apt-get install -y memcached. I have set up memcached servers that handle tens of thousands of queries per second and it has never been a concern.

In any event, you're much better off doing full-page caching using tools designed for this task, such as Varnish. As a bonus, you get tools such as varnishtop, varnishlog and varnishstat to monitor your cache.

The whole point of HTTP is to be architected such that intermediate proxies such as Varnish are transparent accelerators.

“I just feel it’s overused.” — e.g. You wanted to use nginx and Redis, and needed to justify away from the simple solution.

It should be a smell that instead of doing full-page caching in Varnish, you’ve instead rolled your own full-page application layer caching. Varnish handles POSTs, it handles logins (configured via VCL). This solution is a hack. I applaud your performance, but it’s rather nonsensical.

Furthermore, memcached is not difficult to run — it’s a single daemon that requires less setup than Redis! And no persistent storage.

Final note: “Redis is an open source flat file database server – meaning it’s an optimized key value store for your system.” — this is somewhat nonsense. Redis is a fast datastructure-oriented KV store that happens to be able to persist state to disk, but is by no means a ‘flat file database server’ and I’m not sure how that implies that it’s an optimized KV store.

I 'm curious why you are still invoking PHP and not serving the cached page directly from Redis with Nginx.

I believe that detecting the prescense of cookies, HTTP methods and and request paramters are all supported using the buitlin "if" block and standard HTTP module variables.

Since when has memcached been hard to configure, most times I've left it in either the default settings or upped the memory allocation. If you're going to treat Redis like a cache you should really be looking at memcached.

"best of all, it’s open source" -- Open Source should never be the tickbox on a feature set that wins over another product. Look what the product provides now and into the future with the less work -- just because you can change or view the source code doesn't mean it's going to grow with you.