Explorar o código

Update performance numbers in the related FAQ section.

We use newer version of PHP, phpiredis, phpredis, Redis and Ubuntu.

[ci skip]
Daniele Alessandri %!s(int64=12) %!d(string=hai) anos
pai
achega
49aa6f0aca
Modificáronse 1 ficheiros con 16 adicións e 16 borrados
  1. 16 16
      FAQ.md

+ 16 - 16
FAQ.md

@@ -79,18 +79,18 @@ _________________________________________________
 ### Predis is a pure-PHP implementation: it can not 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 11.04 (running on a Intel Q6600):
+a couple of easy numbers using a single Predis client with PHP 5.4.7 (custom build) and Redis 2.2
+(localhost) under Ubuntu 12.04.1 (running on a Intel Q6600):
 
-    19600 SET/sec using 12 bytes for both key and value
-    18900 GET/sec while retrieving the very same values
-    0.200 seconds to fetch 30000 keys using _KEYS *_.
+    21500 SET/sec using 12 bytes for both key and value
+    21000 GET/sec while retrieving the very same values
+    0.130 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)?
 
-    30500 SET/sec using 12 bytes for both key and value
-    31000 GET/sec while retrieving the very same values
-    0.030 seconds to fetch 30000 keys using "KEYS *"".
+    30100 SET/sec using 12 bytes for both key and value
+    29400 GET/sec while retrieving the very same values
+    0.035 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
@@ -104,14 +104,14 @@ Redis, but how these numbers change when we hit the network by connecting to ins
 reside on other servers?
 
     Using Predis:
-    3600 SET/sec using 12 bytes for both key and value
-    3600 GET/sec while retrieving the very same values
-    0.210 seconds to fetch 30000 keys using "KEYS *".
+    3200 SET/sec using 12 bytes for both key and value
+    3200 GET/sec while retrieving the very same values
+    0.132 seconds to fetch 30000 keys using "KEYS *".
 
     Using phpredis:
-    4000 SET/sec using 12 bytes for both key and value
-    4000 GET/sec while retrieving the very same values
-    0.051 seconds to fetch 30000 keys using "KEYS *".
+    3500 SET/sec using 12 bytes for both key and value
+    3500 GET/sec while retrieving the very same values
+    0.045 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
@@ -139,8 +139,8 @@ _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.031 seconds from a local Redis instance
-    0.058 seconds from a remote Redis instance
+    0.035 seconds from a local Redis instance
+    0.047 seconds from a remote Redis instance
 
 
 ### If I need to install a C extension to get better performances, why not using phpredis? ###