As some of you might know I’m the author and maintainer of Predis, a pure-PHP client library for Redis. When I started this project back in mid-2009 Redis was a very young yet promising NoSQL key-value store with only three client libraries available for PHP (one of which was a C-based extension that eventually led to phpredis) offering support only for the Redis commands implemented at that time, and plagued by many bugs. Fast forward to date, and both Predis and phpredis are now the two most used, stable and up-to-date clients in PHP-land among the bunch available. Although it’s mostly a one-man project, I’m very proud of the work behind its development and thankful for the contributions received from the community.
So why am I writing this blog post? To cut it straight to the point, I think there’s sometimes a little misconception about the very reason for which Predis exists nowadays and Aleksey’s recent blog post is offering me a good opportunity to clarify things a bit. Don’t get me wrong he made various valid points, but what has actually caught my attention and prompted me to write this post is the very introduction:
As some of you may know, I’m crazy about speed. So when I saw that people were happily using Predis as their choice of PHP client for Redis, I was a bit confused.
Why use a client written in PHP for something that should be ‘fast’ like Redis?
That kind of defeats the purpose - unless you don’t really care about response times and scalability.
Predis was initially developed to fill the lack for a decent client library but turned into a more comprehensive solution allowing for maximum extensibility. In a sense, you may think of this library not only as a mere client for Redis but as a sort of framework (pass me the buzzword) with various building blocks that developers can leverage to create abstractions for features based upon Redis and expose them through a consistent interface. In my opinion a great example of such extensibility is the abstraction used to support Lua scripts exposing them as if they were common Redis operations such as GET or SET (and it works when using client-side sharding or master/slave replication too). Some parts were also reused to build a fully-asynchronous version of the client!
Obviously there’s a price to pay for everything and, in our case, that price is a penalty in raw speed compared to a C-based extension due to the undeniable greater overhead of a pure-PHP implementation. You can mitigate part of this overhead by using PHP >= 5.4 (faster at method dispatching), an opcode cache (you should do that anyway on production servers) or even plugging in phpiredis for faster protocol (de)serialization, but in the end you are optimizing your stack on a single-server basis. You can have 5, 10, 100 servers hitting Redis for distributed operations: that’s where Redis shines the best and that’s why it’s considered blazing fast. In such distributed scenarios, when one or more Redis instances are running on remote hosts, you will soon notice that most of the difference in speed is lost due to network round-trip times so you will be left for the most part with the inherent overhead of compiling the source code (or loading the cached opcodes) of Predis on each request. We’ve always been clear on what to expect out of Predis in this case and this is the reason why we have a FAQ about performances shipped along with the library. It’s a matter of trade offs: you sacrifice a low overhead for the sake of flexibility.
But then again, is it possible to use Predis when you also need decent overall performances or scalability? Depending on your definition of “decent performances” in the context of your application and provided a correct setup and architecture, yes. I personally know of a few high-load web sites using Predis, each one with a different reason behind their choice. Sure, if you don’t need fancy features and you only have one server performing requests against Redis running on the localhost then you would probably prefer to stick with phpredis thanks to its lower overhead, but that doesn’t mean being able to scale. Is Predis better than phpredis, or the other way around? Simply put, they are two solutions to the same problem and both have their different strong and weak points. In the end you are the one to decide based on your needs but, more importantly and as Aleksey concluded, don’t base your decisions on assumptions. And, I’d just like to add, not even on general benchmarks.