About Predis and benchmarks: why a pure-PHP Redis client anyway?

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.


Puoi scrivere un commento oppure inviare un trackback dal tuo sito.

17 commenti a “About Predis and benchmarks: why a pure-PHP Redis client anyway?”

  1. Totally agree - performance isn't an absolute quality, but rather is derived from your requirements. BTW - Predis is a great Redis client, thanks for creating it!

  2. What's up colleagues, good paragraph and nice arguments commented at this place, I am truly enjoying by these.

  3. Very good post! We will be linking to this particularly
    great article on our site. Keep up the great writing.

  4. Wonderful, what a weblog it is! This web site
    presents helpful facts to us, keep it up.

  5. Good replies in return of this issue with genuine arguments and explaining the whole
    thing on the topic of that.

  6. It's amazing to visit this web page and reading
    the views of all colleagues concerning this article, while I am also eager of getting knowledge.

  7. That is a very good tip particularly to those fresh to the
    blogosphere. Simple but very precise info… Thank you for
    sharing this one. A must read article!

  8. It's remarkable in support of me to have a website, which is
    beneficial in support of my experience. thanks admin

  9. It's amazing for me to have a site, which is good for my experience.
    thanks admin

  10. Good web site you have here.. It's hard to find high-quality writing
    like yours these days. I seriously appreciate people like you!
    Take care!!

  11. Hi there, just became aware of your blog through Google, and found that it's really informative.
    I'm gonna watch out for brussels. I'll appreciate if you continue this in future.
    Numerous people will be benefited from your writing.
    Cheers!

  12. I got this site from my pal who shared with
    me on the topic of this web site and at the moment this time I am browsing
    this site and reading very informative posts here.

  13. Good blog you have got here.. It's difficult to find high-quality writing like yours
    these days. I seriously appreciate individuals like you!
    Take care!!

  14. What's up, this weekend is good for me,
    as this point in time i am reading this impressive educational article here at my residence.

  15. This piece of writing presents clear idea in support of the
    new visitors of blogging, that actually how to do running a blog.

  16. Hmm it appears like your website ate my first comment (it was extremely long) so I guess I'll just sum it up what I submitted and say, I'm thoroughly enjoying your blog.
    I too am an aspiring blog writer but I'm still new to the whole thing.
    Do you have any suggestions for newbie blog writers?
    I'd definitely appreciate it.

  17. That is a good tip especially to those fresh to the blogosphere.
    Short but very precise information… Thank you for sharing this one.

    A must read article!

Lascia un commento

Puoi utilizzare i seguenti tag XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>