summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* DEBUG embstr-classes added.freelistantirez2014-05-081-0/+12
|
* Use a free list for EMBSTR objects creation / release.antirez2014-05-081-7/+43
| | | | | | | | | | | | | | To my surprise, mantaining a small poll of objects provides a very big speedup even when the jemalloc allocator is used, which is supposed to have arenas doing mostly the same work. Probably this is a combination of different factors: 1) No need to manage zmalloc total memory used. 2) No locking of any kind because we can assume single thread, so maintaining the free list may be cheaper for us compared to jemalloc. 3) More locality because of a different cache/reuse pattern?
* REDIS_ENCODING_EMBSTR_SIZE_LIMIT set to 39.antirez2014-05-071-2/+5
| | | | | | The new value is the limit for the robj + SDS header + string + null-term to stay inside the 64 bytes Jemalloc arena in 64 bits systems.
* Scripting: objects caching for Lua c->argv creation.antirez2014-05-071-3/+40
| | | | | | 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.
* Scripting: Use faster API for Lua client c->argv creation.antirez2014-05-071-3/+6
| | | | | | | 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.
* Scripting: don't call lua_gc() after Lua script run.antirez2014-05-071-1/+17
| | | | | | | | 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%.
* Scripting: cache argv in luaRedisGenericCommand().antirez2014-05-071-4/+15
| | | | ~ 4% consistently measured speed improvement.
* Fixed missing c->bufpos reset in luaRedisGenericCommand().antirez2014-05-071-0/+1
| | | | | Bug introduced when adding a fast path to avoid copying the reply buffer for small replies that fit into the client static buffer.
* Scripting: replace tolower() with faster code in evalGenericCommand().antirez2014-05-071-1/+5
| | | | | | 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.
* Scripting: luaRedisGenericCommand() fast path for buffer-only replies.antirez2014-05-071-7/+15
| | | | | | 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.
* Define HAVE_ATOMIC for clang.antirez2014-05-071-1/+1
|
* Scripting: simpler reply buffer creation in luaRedisGenericCommand().antirez2014-05-071-5/+2
| | | | | 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().
* CLUSTER SET-CONFIG-EPOCH implemented.antirez2014-04-291-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | Initially Redis Cluster accepted that after cluster creation all the nodes were at configEpoch 0, evolving from zero as failovers happen. However later the semantic was made more strict in order to make sure a cluster has always all the master nodes with a different configEpoch, which is more robust in some corner case (especially resulting from errors by the system administrator). To assign different configEpochs to different nodes at startup was a task performed naturally by the config conflicts resolution algorithm (see the Cluster specification). However this works well only for small clusters or when there are actually just a few collisions, since it is designed for exceptional cases. When a large cluster is created hundred of nodes can be at epoch 0, so the conflict resolution code is slow to provide an unique config to each node. For this reason this new command was introduced. It can be called only when a node is totally fresh: no other nodes known, and configEpoch set to zero, so it is safe even against misuses. redis-trib will use the new command in order to start the cluster already setting an incremental unique config to every node.
* CLIENT LIST speedup via peerid caching + smart allocation.antirez2014-04-285-25/+43
| | | | | | | | This commit adds peer ID caching in the client structure plus an API change and the use of sdsMakeRoomFor() in order to improve the reallocation pattern to generate the CLIENT LIST output. Both the changes account for a very significant speedup.
* Use sdscatfmt() in getClientInfoString() to make it faster.antirez2014-04-282-9/+10
|
* Added new sdscatfmt() %u and %U format specifiers.antirez2014-04-281-4/+71
| | | | | | This commit also fixes a bug in the implementation of sdscatfmt() resulting from stale references to the SDS string header after sdsMakeRoomFor() calls.
* sdscatfmt() added to SDS library.antirez2014-04-281-27/+165
| | | | | | | | | | | | sdscatprintf() relies on printf() family libc functions and is sometimes too slow in critical code paths. sdscatfmt() is an alternative which is: 1) Far less capable. 2) Format specifier uncompatible. 3) Faster. It is suitable to be used in those speed critical code paths such as CLIENT LIST output generation.
* Process events with processEventsWhileBlocked() when blocked.antirez2014-04-245-4/+27
| | | | | | | | 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).
* Accept multiple clients per iteration.antirez2014-04-242-17/+33
| | | | | | | | | | | | | | 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.
* AE_ERR -> ANET_ERR in acceptUnixHandler().antirez2014-04-241-1/+1
| | | | No actual changes since the value is the same.
* While ANET_ERR is -1, check syscall retval for -1 itself.antirez2014-04-241-2/+2
|
* clusterLoadConfig() REDIS_ERR retval semantics refined.antirez2014-04-241-1/+10
| | | | | | | We should return REDIS_ERR to signal we can't read the configuration because there is no config file only after checking errno, othewise we risk to rewrite an existing file that was not accessible for some other reason.
* Lock nodes.conf to avoid multiple processes using the same file.antirez2014-04-241-0/+62
| | | | | | | | | This was a common source of problems among users. The solution adopted is not bullet-proof as if the user deletes the nodes.conf file manually, and starts a new instance with the same nodes.conf file path, two instances will use the same file. However following this reasoning the user may drop a nuclear bomb into the datacenter as well.
* Merge pull request #1677 from mattsta/expire-before-deleteSalvatore Sanfilippo2014-04-231-0/+1
|\ | | | | Check key expiration before deleting
| * Check key expiration before deletingMatt Stancliff2014-04-101-0/+1
| | | | | | | | | | | | Deleting an expired key should return 0, not success. Fixes #1648
* | fix null pointer access with no file pointerGlauber Costa2014-04-231-1/+1
| | | | | | | | | | | | 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.
* | Merge pull request #1701 from kingsumos/node_descriptionSalvatore Sanfilippo2014-04-231-1/+1
|\ \ | | | | | | fix cluster node description showing wrong slot allocation
| * | fix cluster node description showing wrong slot allocationkingsumos2014-04-221-1/+1
| | |
* | | Missing return REDIS_ERR added to processMultibulkBuffer().antirez2014-04-231-1/+3
| | | | | | | | | | | | | | | | | | | | | 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.
* | | redis-cli help.h updated.antirez2014-04-221-2/+73
| | |
* | | ZREMRANGEBYLEX memory leak removed calling zslFreeLexRange().antirez2014-04-181-2/+5
| | |
* | | Speedup hllRawSum() processing 8 bytes per iteration.antirez2014-04-171-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Speedup SUM(2^-reg[m]) in HyperLogLog computation.antirez2014-04-171-4/+8
| | | | | | | | | | | | | | | | | | 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.
* | | PFCOUNT support for multi-key union.antirez2014-04-172-6/+73
| | |
* | | HyperLogLog low level merge extracted from PFMERGE.antirez2014-04-171-39/+54
| | |
* | | ZREMRANGEBYLEX implemented.antirez2014-04-173-0/+77
|/ /
* | Always pass sorted set range objects by reference.antirez2014-04-173-49/+51
| |
* | ZREMRANGE* commands refactored into a single generic function.antirez2014-04-171-65/+58
| |
* | Pass by pointer and release of lex ranges.antirez2014-04-161-15/+42
| | | | | | | | | | | | | | 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.
* | ZLEXCOUNT implemented.antirez2014-04-163-0/+75
| | | | | | | | Like ZCOUNT for lexicographical ranges.
* | HyperLogLog invalid representation error code set to INVALIDOBJ.antirez2014-04-161-7/+7
| |
* | PFDEBUG TODENSE added.antirez2014-04-161-0/+15
| | | | | | | | Converts HyperLogLogs from sparse to dense. Used for testing.
* | User-defined switch point between sparse-dense HLL encodings.antirez2014-04-154-6/+18
| |
* | PFSELFTEST improved with sparse encoding checks.antirez2014-04-151-4/+29
| |
* | PFDEBUG ENCODING added.antirez2014-04-141-0/+7
| |
* | Set HLL_SPARSE_MAX to 3000.antirez2014-04-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Error message for invalid HLL objects unified.antirez2014-04-141-5/+7
| |
* | PFMERGE fixed to work with sparse encoding.antirez2014-04-141-8/+45
| |
* | Mark PFDEBUG as write command in the commands table.antirez2014-04-141-1/+1
| | | | | | | | It is safer since it is able to have side effects.
* | Correctly replicate PFDEBUG GETREG.antirez2014-04-141-3/+6
| | | | | | | | | | Even if it is a debugging command, make sure that when it forces a change in encoding, the command is propagated.