- 22 May, 2014 3 commits
-
-
antirez authored
When we are blocked and a few events a processed from time to time, it is smarter to call the event handler a few times in order to handle the accept, read, write, close cycle of a client in a single pass, otherwise there is too much latency added for clients to receive a reply while the server is busy in some way (for example during the DB loading).
-
antirez authored
When the listening sockets readable event is fired, we have the chance to accept multiple clients instead of accepting a single one. This makes Redis more responsive when there is a mass-connect event (for example after the server startup), and in workloads where a connect-disconnect pattern is used often, so that multiple clients are waiting to be accepted continuously. As a side effect, this commit makes the LOADING, BUSY, and similar errors much faster to deliver to the client, making Redis more responsive when there is to return errors to inform the clients that the server is blocked in an not interruptible operation.
-
antirez authored
-
- 20 May, 2014 4 commits
-
-
antirez authored
-
michael-grunder authored
When scanning the argument list inside of a redis.call() invocation for pre-cached values, there was no check being done that the argument we were on was in fact within the bounds of the cache size. So if a redis.call() command was ever executed with more than 32 arguments (current cache size #define setting) redis-server could segfault.
-
antirez authored
-
antirez authored
-
- 19 May, 2014 2 commits
-
-
antirez authored
-
Mike Trinkala authored
Set the MSB as documented.
-
- 14 May, 2014 1 commit
-
-
antirez authored
No REDIS_ENCODING_EMBSTR in 2.8 internals.
-
- 12 May, 2014 3 commits
-
-
Akos Vandra authored
(Note: commit message modified by @antirez for clarity).
-
Akos Vandra authored
-
antirez authored
-
- 09 May, 2014 1 commit
-
-
antirez authored
-
- 08 May, 2014 2 commits
-
-
antirez authored
When a Sentinel performs a failover (successful or not), or when a Sentinel votes for a different Sentinel trying to start a failover, it sets a min delay before it will try to get elected for a failover. While not strictly needed, because if multiple Sentinels will try to failover the same master at the same time, only one configuration will eventually win, this serialization is practically very useful. Normal failovers are cleaner: one Sentinel starts to failover, the others update their config when the Sentinel performing the failover is able to get the selected slave to move from the role of slave to the one of master. However currently this timeout was implicit, so users could see Sentinels not reacting, after a failed failover, for some time, without giving any feedback in the logs to the poor sysadmin waiting for clues. This commit makes Sentinels more verbose about the delay: when a master is down and a failover attempt is not performed because the delay has still not elaped, something like that will be logged: Next failover delay: I will not start a failover before Thu May 8 16:48:59 2014
-
antirez authored
This event makes clear, before the switch-master event is generated, that a Sentinel received a configuration update from another Sentinel.
-
- 07 May, 2014 11 commits
-
-
antirez authored
SPOP, tested in the new test, is among the commands rewritng the client->argv argument vector (it gets rewritten as SREM) for command replication purposes. Because of recent optimizations to client->argv caching in the context of the Lua internal Redis client, it is important to test for SPOP to be callable from Lua without bad effects to the other commands.
-
antirez authored
Sometimes the process is still there but no longer in a state that can be checked (after being killed). This used to happen after a call to SHUTDOWN NOSAVE in the scripting unit, causing a false positive.
-
antirez authored
Reusing small objects when possible is a major speedup under certain conditions, since it is able to avoid the malloc/free pattern that otherwise is performed for every argument in the client command vector.
-
antirez authored
Replace the three calls to Lua API lua_tostring, lua_lua_strlen, and lua_isstring, with a single call to lua_tolstring. ~ 5% consistent speed gain measured.
-
antirez authored
Calling lua_gc() after every script execution is too expensive, and apparently does not make the execution smoother: the same peak latency was measured before and after the commit. This change accounts for scripts execution speedup in the order of 10%.
-
antirez authored
~ 4% consistently measured speed improvement.
-
antirez authored
Bug introduced when adding a fast path to avoid copying the reply buffer for small replies that fit into the client static buffer.
-
antirez authored
The function showed up consuming a non trivial amount of time in the profiler output. After this change benchmarking gives a 6% speed improvement that can be consistently measured.
-
antirez authored
When the reply is only contained in the client static output buffer, use a fast path avoiding the dynamic allocation of an SDS string to concatenate the client reply objects.
-
antirez authored
-
antirez authored
It if faster to just create the string with a single sdsnewlen() call. If c->bufpos is zero, the call will simply be like sdsemtpy().
-
- 23 Apr, 2014 5 commits
-
-
Matt Stancliff authored
Verify proper expire-before-delete behavior. This test passes with the expire-before-delete commit and fails without it.
-
Matt Stancliff authored
Deleting an expired key should return 0, not success. Fixes #1648
-
Glauber Costa authored
I happen to be working on a system that lacks urandom. While the code does try to handle this case and artificially create some bytes if the file pointer is empty, it does try to close it unconditionally, leading to a segfault.
-
Salvatore Sanfilippo authored
Fixed typos.
-
antirez authored
When we set a protocol error we should return with REDIS_ERR to let the caller know it should stop processing the client. Bug found in a code auditing related to issue #1699.
-
- 22 Apr, 2014 4 commits
-
-
Kevin Menard authored
-
antirez authored
-
antirez authored
-
antirez authored
-
- 18 Apr, 2014 4 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
The internal HLL raw encoding used by PFCOUNT when merging multiple keys is aligned to 8 bits (1 byte per register) so we can exploit this to improve performances by processing multiple bytes per iteration. In benchmarks the new code was several times faster with HLLs with many registers set to zero, while no slowdown was observed with populated HLLs.
-