- 02 Jul, 2014 11 commits
- 01 Jul, 2014 8 commits
-
-
antirez authored
It is not a good idea to bloat the code with gettimeofday() calls if the instance is working well, and turning monitoring on at runtime is a joke.
-
antirez authored
-
antirez authored
Instead we update the old sample with the new latency if it is greater.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
We introduce the distinction between slow and fast commands since those are two different sources of latency. An O(1) or O(log N) command without side effects (can't trigger deletion of large objects as a side effect of its execution) if delayed is a symptom of inherent latency of the system. A non-fast command (commands that may run large O(N) computations) if delayed may just mean that the user is executing slow operations. The advices LATENCY should provide in this two different cases are different, so we log the two classes of commands in a separated way.
-
antirez authored
-
- 30 Jun, 2014 3 commits
- 27 Jun, 2014 6 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
This fixes detection of wrong subcommand (that resulted in the default all-commands output instead) and allows COMMAND INFO to be called without arguments (resulting into an empty array) which is useful in programmtically generated calls like the following (in Ruby): redis.commands("command","info",*mycommands) Note: mycommands may be empty.
-
antirez authored
-
antirez authored
Static was removed since it is needed in order to get symbols in stack traces. Minor changes in the source code were operated to make it more similar to the existing Redis code base.
-
Matt Stancliff authored
COMMANDS returns a nested multibulk reply for each command in the command table. The reply for each command contains: - command name - arity - array of command flags - start key position - end key position - key offset step - optional: if the keys are not deterministic and Redis uses an internal key evaluation function, the 6th field appears and is defined as a status reply of: REQUIRES ARGUMENT PARSING Cluster clients need to know where the keys are in each command to implement proper routing to cluster nodes. Redis commands can have multiple keys, keys at offset steps, or other issues where you can't always assume the first element after the command name is the cluster routing key. Using the information exposed by COMMANDS, client implementations can have live, accurate key extraction details for all commands. Also implements COMMANDS INFO [commands...] to return only a specific set of commands instead of all 160+ commands live in Redis.
-
- 26 Jun, 2014 9 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
Technically the problem is due to the client type API that does not return a special value for the master, however fixing it locally in the CLIENT KILL command is better currently because otherwise we would introduce a new output buffer limit class as a side effect.
-
antirez authored
Added for debugging and forgot there.
-
antirez authored
This is supposed to fix issue #1417, but we'll know if this is enough only after a couple of runs of the CI test without false positives.
-
Salvatore Sanfilippo authored
PowerPC compile-time improvements
-
Matt Stancliff authored
From mailing list post https://groups.google.com/forum/#!topic/redis-db/D3k7KmJmYgM In the file “config.h”, the definition HAVE_ATOMIC is used to indicate if an architecture on which redis is implemented supports atomic synchronization primitives. Powerpc supports atomic synchronization primitives, however, it is not listed as one of the architectures supported in config.h. This patch adds the __powerpc__ to the list of architectures supporting these primitives. The improvement of redis due to the atomic synchronization on powerpc is significant, around 30% to 40%, over the default implementation using pthreads. This proposal adds __powerpc__ to the list of architectures designated to support atomic builtins.
-
Matt Stancliff authored
From mailing list post https://groups.google.com/forum/#!topic/redis-db/QLjiQe4D7LA In zmalloc.c the following primitives are currently used to synchronize access to single global variable: __sync_add_and_fetch __sync_sub_and_fetch In some architectures such as powerpc these primitives are overhead intensive. More efficient C11 __atomic builtins are available with newer GCC versions, see http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/_005f_005fatomic-Builtins.html#_005f_005fatomic-Builtins By substituting the following __atomic… builtins: __atomic_add_fetch __atomic_sub_fetch the performance improvement on certain architectures such as powerpc can be significant, around 10% to 15%, over the implementation using __sync builtins while there is only slight uptick on Intel architectures because it was already enforcing Intel Strongly ordered memory semantics. The selection of __atomic built-ins can be predicated on the definition of ATOMIC_RELAXED which Is available on in gcc 4.8.2 and later versions.
-
Matt Stancliff authored
-
- 25 Jun, 2014 3 commits
-
-
antirez authored
-
antirez authored
While we have to output failing masters in order to provide an accurate map (that may be the one of a Redis Cluster in down state because not all slots are served by a working master), to provide slaves in FAIL state is not a good idea since those are not necesarely needed, and the client will likely incur into a latency penalty trying to connect with a slave which is down. Note that this means that CLUSTER SLOTS does not provide a *complete* map of slaves, however this would not be of any help since slaves may be added later, and a client that needs to scale reads and requires to stay updated with the list of slaves, need to do a refresh of the map from time to time, anyway.
-
antirez authored
-