Comparison between redis client predis and phpredis

There is a FAQ in the predis directory. markdown file, FAQ Frequently Asked Questions in Chinese. This document compares and analyzes the redis client predis and phpredis, and describes the advantages and disadvantages. It is still clear in the documentation of foreigners, at first glance, we can see that, of course, the comparison results with our own tests are still somewhat different. Further tests are required.

 

# Some Frequently Asked Questions about predis #
____________________________________________

### What is the point of predis? ###

The main point of predis is about offering a highly customizable client for redis that can be easily
Extended by developers while still being reasonabily fast. With predis you can swap almost any class
Used internally with your own impm implementation: You can build connection classes, or new
Distribution strategies for client-side sharding, or class handlers to replace existing commands or
Add new ones. All of this can be achieved without messing with the source code of the library and
Directly in your own application. Given the fast pace at which redis is developed and adds new
Features, this can be a great asset that allows you to add new and still missing features or commands,
Or change the behaviour of the library without the need to break your dependencies in production code
(Well, at least to some degree ).

### Nice, but it is still a pure-PHP implementation: It can't be fast enough! ###

It really depends, but most of the times the answer is: _ Yes, it is fast enough _. I will give you
A couple of easy numbers using a single predis client with PHP 5.3.5 (custom build) and redis 2.2
(Localhost) under Ubuntu 10.10 (running on a intel q6600 ):

18900 set/sec using 12 bytes for both key and Value
18300 get/sec while retrieving the very same values
0.210 seconds to fetch 30000 keys using _ keys *_.

How does it compare with a nice C-based extension such as [_ phpredis _] (http://github.com/nicolasff/phpredis )?

29000 set/sec using 12 bytes for both key and Value
30000 get/sec while retrieving the very same values
0.037 seconds to fetch 30000 keys using "keys *"".

Wow, _ phpredis _ looks so much faster! Well we are comparing a C extension with a pure-PHP library so
Lower numbers are quite expected, but there is a fundamental flaw in them: Is this really how you are
Going to use redis in your application? Are you really going to send thousands of commands in a for-Loop
For each page request using a single client instance? If so, well I guess you are probably doing something
Wrong. Also, if you need to set or get multiple keys you shoshould definitely use commands such as mset and
Mget. You can also use pipelining to get more than CES when this technique can be used.

There is one more thing. We have tested the overhead of predis by connecting on a localhost instance
Redis, but how these numbers change when we hit the network by connecting to instances of redis that
Reside on other servers?

Using predis:
3150 set/sec using 12 bytes for both key and Value
3150 get/sec while retrieving the very same values
0.212 seconds to fetch 30000 keys using "keys *".

Using phpredis:
3300 set/sec using 12 bytes for both key and Value
3300 get/sec while retrieving the very same values
0.088 seconds to fetch 30000 keys using "keys *".

There you go, you get almost the same average numbers and the reason is quite simple: network latency
Is a real performance killer and you cannot do (almost) Anything about that. As a disclaimer, please
Remember that we are measuring the overhead of client libraries implementations and the effects of
Network round-trip time, we are not really measuring how fast redis is. redis shines the best
Thousands of concurrent clients doing requests! Also, actual performances shocould be measured according
To how your application will use redis.

### I am convinced, but performances for multi-bulk replies (e.g. _ keys * _) are still worse ###

Fair enough, but there is actually an option for you if you need even more speed and it consists on
Installing _ [phpiredis] (http://github.com/seppo0010/phpiredis) _ (note the additional _ I _ in
Name) and let predis using it. _ phpiredis _ is a C-based extension that wraps _ hiredis _ (
Official redis C client library) with a thin layer that exposes its features to PhP. You will now
Get the benefits of a faster Protocol Parser just by adding a single line of code in your application:

Predis/client: defineconnection ('tcp ','/predis/Network/phpiredisconnection ');

As simple as it is, nothing will really change in the way you use the library in your application. So,
How fast is it now? There are not much improvements for inline or short bulk replies (e.g. _ SET _ or
_ GET _), but the speed for parsing multi-bulk replies is now on par with phpredis:

Using predis with a phpiredis-based connection to fetch 30000 keys using _ keys *_:

0.037 seconds from a local redis instance
0.081 seconds from a remote redis instance

### If I need to install a C extension to get better performances, why not using phpredis? ###

Good question. Generically speaking, if you need absolute uber-speed using localhost instances of redis
And you do not care about into actions built around und some redis features such as multi/exec, or if you
Do not need any kind of extensibility or guaranteed backwards compatibility with different versions
Redis (predis currently supports from 1.2 up to 2.2, and even the current development version), then
Using _ phpredis _ can make sense for you. Otherwise, predis is for you. Using _ phpiredis _ gives you
A nice speed bump, but it is not mandatory.

### Why PHP 5.3? ###

Seriously, are you still using PHP 5.2 to build new applications? I assume that if you are throwing redis
In the mix, then you are probably coding something new after all. php 5.3 is faster, less memory hungry
And has a few nice features such as namespaces and closures (kind of). More importantly, PHP 5.2 is not
Even officially supported anymore (aside from security patches). php 5.3 is not the future of PHP,
Its current present. Furthermore, most of the existing frameworks out there are also making the switch
With their respective new major versions. If you still insist on using PHP 5.2, you can get any recent
Backported release of predis 0.6.x, or just use a different library.