- 09 5月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 08 5月, 2014 2 次提交
-
-
由 antirez 提交于
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 提交于
This event makes clear, before the switch-master event is generated, that a Sentinel received a configuration update from another Sentinel.
-
- 07 5月, 2014 9 次提交
-
-
由 antirez 提交于
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 提交于
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 提交于
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 提交于
~ 4% consistently measured speed improvement.
-
由 antirez 提交于
Bug introduced when adding a fast path to avoid copying the reply buffer for small replies that fit into the client static buffer.
-
由 antirez 提交于
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 提交于
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 提交于
-
由 antirez 提交于
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 4月, 2014 3 次提交
-
-
由 Matt Stancliff 提交于
Deleting an expired key should return 0, not success. Fixes #1648
-
由 Glauber Costa 提交于
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.
-
由 antirez 提交于
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 4月, 2014 2 次提交
- 18 4月, 2014 8 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
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.
-
由 antirez 提交于
When the register is set to zero, we need to add 2^-0 to E, which is 1, but it is faster to just add 'ez' at the end, which is the number of registers set to zero, a value we need to compute anyway.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
- 17 4月, 2014 1 次提交
-
-
由 antirez 提交于
Given that the code was written with a 2 years pause... something strange happened in the middle. So there was no function to free a lex range min/max objects, and in some places the range was passed by value.
-
- 16 4月, 2014 14 次提交
-
-
由 antirez 提交于
Like ZCOUNT for lexicographical ranges.
-
由 antirez 提交于
-
由 antirez 提交于
Converts HyperLogLogs from sparse to dense. Used for testing.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
After running a few benchmarks, 3000 looks like a reasonable value to keep HLLs with a few thousand elements small while the CPU cost is still not huge. This covers all the cases where the dense representation would use N orders of magnitude more space, like in the case of many HLLs with carinality of a few tens or hundreds. It is not impossible that in the future this gets user configurable, however it is easy to pick an unreasoable value just looking at savings in the space dimension without checking what happens in the time dimension.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
It is safer since it is able to have side effects.
-
由 antirez 提交于
Even if it is a debugging command, make sure that when it forces a change in encoding, the command is propagated.
-
由 antirez 提交于
If we converted to dense, a register must be updated in the dense representation.
-
由 antirez 提交于
Mostly by reordering opcodes check conditional by frequency of opcodes in larger sparse-encoded HLLs.
-
由 antirez 提交于
-