FAQ 5.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990
  1. # Some frequently asked questions about Predis #
  2. ____________________________________________
  3. ### What is the point of Predis? ###
  4. The main point of Predis is about offering a highly customizable client for Redis that can be easily
  5. extended by developers while still being reasonabily fast. With Predis you can swap almost any class
  6. used internally with your own custom implementation: you can build connection classes, or new
  7. distribution strategies for client-side sharding, or class handlers to replace existing commands or
  8. add new ones. All of this can be achieved without messing with the source code of the library and
  9. directly in your own application. Given the fast pace at which Redis is developed and adds new
  10. features, this can be a great asset that allows you to add new and still missing features or commands,
  11. or change the behaviour of the library without the need to break your dependencies in production code
  12. (well, at least to some degree).
  13. ### Nice, but it is still a pure-PHP implementation: it can't be fast enough! ###
  14. It really depends, but most of the times the answer is: _yes, it is fast enough_. I will give you
  15. a couple of easy numbers using a single Predis client with PHP 5.3.5 (custom build) and Redis 2.2
  16. (localhost) under Ubuntu 10.10 (running on a Intel Q6600):
  17. 18500 SET/sec using 12 bytes for both key and value
  18. 18100 GET/sec while retrieving the very same values
  19. 0.210 seconds to fetch 30000 keys using _KEYS *_.
  20. How does it compare with a nice C-based extension such as [__phpredis__](http://github.com/owlient/phpredis)?
  21. 29000 SET/sec using 12 bytes for both key and value
  22. 30000 GET/sec while retrieving the very same values
  23. 0.037 seconds to fetch 30000 keys using _KEYS *_.
  24. Wow, __phpredis__ looks so much faster! Well we are comparing a C extension with a pure-PHP library so
  25. lower numbers are quite expected, but there is a fundamental flaw in them: is this really how you are
  26. going to use Redis in your application? Are you really going to send thousands of commands for each page
  27. request using a single client instance? If so, well I guess you are probably doing something wrong.
  28. Also, if you need to SET or GET multiple keys you should definitely use commands such as MSET and MGET.
  29. You can also use pipelining to get more performances when this technique can be used.
  30. There is one more thing. We have tested the overhead of Predis by connecting on a localhost instance
  31. of Redis, but how these numbers change when we hit the network by connecting to instances of Redis
  32. that reside on other servers?
  33. Using Predis:
  34. 3100 SET/sec using 12 bytes for both key and value
  35. 3100 GET/sec while retrieving the very same values
  36. 0.212 seconds to fetch 30000 keys using _KEYS *_.
  37. Using phpredis:
  38. 3300 SET/sec using 12 bytes for both key and value
  39. 3300 GET/sec while retrieving the very same values
  40. 0.088 seconds to fetch 30000 keys using _KEYS *_.
  41. There you go, you get almost the same average numbers and the reason is quite simple: network latency
  42. is a real performance killer and you cannot do (almost) anything about that. As a disclaimer, please
  43. remember that we are measuring the overhead of client libraries implementations and the effects of the
  44. network round-trip time, we are not really measuring how fast Redis is. Redis shines the best with
  45. thousands of concurrent clients doing requests! Also, actual performances should be measured according
  46. to how your application is going to use Redis.
  47. ### I am convinced, but the performances of multi-bulk replies (e.g. _KEYS *_) are still worse ###
  48. Fair enough, but there is actually an option for you if you need even more speed and it consists on
  49. installing __[phpiredis](http://github.com/seppo0010/phpiredis)__ (note the additional _i_ in the
  50. name) and let Predis using it. __phpiredis__ is a C-based extension that wraps __hiredis__ (the
  51. official Redis C client library) with a thin layer that exposes its features to PHP. You will now
  52. get the benefits of a faster protocol parser just by adding a single line of code in your application:
  53. Predis\Client::defineConnection('tcp', '\Predis\Network\PhpiredisConnection');
  54. As simple as it is, nothing will change in the way you use the library in your application. So, how
  55. fast is it now? There are not much improvements for inline or short bulk replies (e.g. SET or GET),
  56. but the speed for parsing multi-bulk replies is now on par with phpredis:
  57. Using Predis with a phpiredis-based connection to fetch 30000 keys using _KEYS *_:
  58. 0.037 seconds from a local Redis instance
  59. 0.081 seconds from a remote Redis instance
  60. ### If I need to install a C extension to get better performances, why not using phpredis? ###
  61. Good question. Generically speaking, if you need absolute uber-speed using localhost instances of Redis
  62. and you do not care about abstractions built around some Redis features such as MULTI / EXEC, or if you
  63. do not need any kind of extensibility or guaranteed backwards compatibility with different versions of
  64. Redis (Predis currently supports from 1.2 up to 2.2, and even the current development version), then
  65. using __phpredis__ can make sense for you. Otherwise, Predis is for you. Using __phpiredis__ gives you
  66. a nice speed bump, but it is not mandatory.