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.

15 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. Hello, іts nice post οn tɦe topiic of media print, ѡе
    all be fmiliar աith media іs a great source оf data.

    Αlso visit mƴ web site - Mailbanger

  3. I visit each day some sites and sites to read posts, however this webpage gives quality based content.

  4. Fantastic beat ! I would like to apprentice
    even as you amend your site, how could i subscribe for
    a blog web site? The account helped me a acceptable deal. I
    have been tiny bit familiar of this your broadcast provided vibrant transparent concept

  5. Great post. I used to be checking continuously this weblog and I'm inspired!
    Extremely helpful info particularly the final phase :)
    I deal with such information much. I was seeking this certain info
    for a very long time. Thanks and best of
    luck.

  6. The art of texting has sort of taken over the world.
    They say: 'I am going to lose thirty pounds,' or 'I am going to quit smoking,' or even 'I am going to get washboard abs.
    Every time I think I'm getting close, I'm tested again and realize
    that I'm not quite there.

  7. Orlando s'est affaibli avec leurs diffe9rents traedsLewis contre Arenas c'e9tait n'importe quoi mais l'e9change avec les Suns c'est vraiement une GROSSE CONNERIE.Pour garder D12, il faudra faire le me9nage et l'entourer de 2 ou 3 ALL STAR genre CP3 .je ne vois que e7a sinon l'anne9e prochaine quand il sera Free Agent il va se barrer fae7on Lebron ou Bosh (sans compensation pour le Magic)

  8. What's up to all, because I am truly keen of reading this webpage's post to be updated regularly.

    It carries pleasant material.

  9. I think that what you published was actually very
    logical. But, what about this? what if you added a little
    information? I mean, I don't wish to tell
    you how to run your website, however what if you
    added something to maybe grab folk's attention? I mean clorophilla.blog

  10. Thank you for any other magnificent article. Where else may just anybody get that kind
    of information in such a perfect way of writing? I've a presentation subsequent week, and I'm at the look for such information.

  11. Everyone loves what you guys tend to be up too. This kind of clever work and reporting!

    Keep up the great works guys I've incorporated you guys to my own blogroll.

  12. I used to be suggested this web site through my cousin. I'm not positive whether this put up is written through him as no
    one else recognise such special about my trouble. You
    are amazing! Thank you!

  13. Right here is the right site for anybody who wishes to find out about this topic.
    You know so much its almost tough to argue with you (not that I actually would want to…HaHa).
    You certainly put a brand new spin on a subject that
    has been written about for many years. Great stuff, just excellent!

  14. Yes! Finally something about free t shirt designs.

  15. Wow! That's a really neat answer!

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=""> <strike> <strong>