1. 12 Sep, 2024 2 commits
    • YaacovHazan's avatar
      Redis 8.0 M01 (#13538) · 5fe3e74a
      YaacovHazan authored
      ### New Features in binary distributions
      
      - 7 new data structures: JSON, Time series, Bloom filter, Cuckoo filter,
      Count-min sketch, Top-k, t-digest
      - Redis scalable query engine (including vector search)
      
      ### Potentially breaking changes
      
      - #12272 `GETRANGE` returns an empty bulk when the negative end index is
      out of range
      - #12395 Optimize `SCAN` command when matching data type
      
      ### Bug fixes
      
      - #13510 Fix `RM_RdbLoad` to enable AOF after RDB loading is completed
      - #13489 `ACL CAT` - return module commands
      - #13476 Fix a race condition in the `cache_memory` of `functionsLibCtx`
      - #13473 Fix incorrect lag due to trimming stream via `XTRIM` command
      - #13338 Fix incorrect lag field in `XINFO` when tombstone is after the
      `last_id` of the consume group
      - #13470 On `HDEL` of last field - update the global hash field
      expiration data structure
      - #13465 Cluster: Pass extensions to node if extension processing is
      handled by it
      - #13443 Cluster: Ensure validity of myself when loading cluster config
      - #13422 Cluster: Fix `CLUSTER SHARDS` command returns empty array
      
      ### Modules API
      
      - #13509 New API calls: `RM_DefragAllocRaw`, `RM_DefragFreeRaw`, and
      `RM_RegisterDefragCallbacks` - defrag API to allocate and free raw
      memory
      
      ### Performance and resource utilization improvements
      
      - #13503 Avoid overhead of comparison function pointer calls in listpack
      `lpFind`
      - #13505 Optimize `STRING` datatype write commands
      - #13499 Optimize `SMEMBERS` command
      - #13494 Optimize `GEO*` commands reply
      - #13490 Optimize `HELLO` command
      - #13488 Optimize client query buffer
      - #12395 Optimize `SCAN` command when matching data type
      - #13529 Optimize `LREM`, `LPOS`, `LINSERT`, and `LINDEX` commands
      - #13516 Optimize `LRANGE` and other commands that perform several
      writes to client buffers per call
      - #13431 Avoid `used_memory` contention when updating from multiple
      threads
      
      ### Other general improvements
      
      - #13495 Reply `-LOADING` on replica while flushing the db
      
      ### CLI tools
      
      - #13411 redis-cli: Fix wrong `dbnum` showed after the client
      reconnected
      
      ### Notes
      
      - No backward compatibility for replication or persistence.
      - Additional distributions, upgrade paths, features, and improvements
      will be introduced in upcoming pre-releases.
      - With the GA release of 8.0 we will deprecate Redis Stack.
      5fe3e74a
    • YaacovHazan's avatar
      Redis 8.0 M01 · 4955375e
      YaacovHazan authored
      4955375e
  2. 11 Sep, 2024 2 commits
  3. 10 Sep, 2024 1 commit
    • Filipe Oliveira (Redis)'s avatar
      Optimize LREM, LPOS, LINSERT, LINDEX: Avoid N-1 sdslen() calls on listTypeEqual (#13529) · bcae7708
      Filipe Oliveira (Redis) authored
      This is a very easy optimization, that avoids duplicate computation of
      the object length for LREM, LPOS, LINSERT na LINDEX.
      
      We can see that sdslen takes 7.7% of the total CPU cycles of the
      benchmarks.
      
      Function Stack | CPU Time: Total | CPU Time: Self | Module | Function
      (Full) | Source File | Start Address
      -- | -- | -- | -- | -- | -- | --
      listTypeEqual | 15.50% | 2.346s | redis-server | listTypeEqual |
      t_list.c | 0x845dd
      sdslen | 7.70% | 2.300s | redis-server | sdslen | sds.h | 0x845e4
      
      Preliminary data showcases 4% improvement in the achievable ops/sec of
      LPOS in string elements, and 2% in int elements.
      bcae7708
  4. 09 Sep, 2024 1 commit
  5. 08 Sep, 2024 1 commit
    • Ozan Tezcan's avatar
      Fix flaky replication tests (#13518) · ac03e372
      Ozan Tezcan authored
      #13495 introduced a change to reply -LOADING while flushing existing db on a replica. Some of our tests are
       sensitive to this change and do no expect -LOADING reply.
      
      Fixing a couple of tests that fail time to time.
      ac03e372
  6. 06 Sep, 2024 1 commit
  7. 05 Sep, 2024 2 commits
  8. 04 Sep, 2024 4 commits
  9. 03 Sep, 2024 7 commits
    • debing.sun's avatar
      Avoid overhead of comparision function pointer calls in lpFind() (#13503) · de7f2f87
      debing.sun authored
      
      
      In #13279 (found by @filipecosta90), for custom lookups, we introduce a
      comparison function for `lpFind()` to compare entry, but it also
      introduces some overhead.
      
      To avoid the overhead of function pointer calls:
      1. Extract the lpFindCb() method into a lpFindCbInternal() method that
      is easier to inline.
      2. Use unlikely to annotate the comparison method, as can only success
      once.
      
      ---------
      Co-authored-by: default avatarOzan Tezcan <ozantezcan@gmail.com>
      de7f2f87
    • Filipe Oliveira (Redis)'s avatar
      changed addReplyHumanLongDouble to addReplyDouble in georadiusGeneric and geoposCommand (#13494) · fb8755a6
      Filipe Oliveira (Redis) authored
      # Summary 
      
      - Addresses https://github.com/redis/redis/issues/11565
      - Measured improvements of 30% and 37% on the simple use-case (GEOSEARCH
      and GEOPOS) (check
      https://github.com/redis/redis/pull/13494#issuecomment-2313668934), and
      of 66% on a dataset with >60M datapoints and pipeline 10 benchmark.
      fb8755a6
    • Meir Shpilraien (Spielrein)'s avatar
      Added new defrag API to allocate and free raw memory. (#13509) · d3d94ccf
      Meir Shpilraien (Spielrein) authored
      All the defrag allocations API expects to get a value and replace it, leaving the old value untouchable.
      In some cases a value might be shared between multiple keys, in such cases we can not simply replace
      it when the defrag callback is called.
      
      To allow support such use cases, the PR adds two new API's to the defrag API:
      
      1. `RM_DefragAllocRaw` - allocate memory base on a given size.
      2. `RM_DefragFreeRaw` - Free the given pointer.
      
      Those API's avoid using tcache so they operate just like `RM_DefragAlloc` but allows the user to split
      the allocation and the memory free operations into two stages and control when those happen.
      
      In addition the PR adds new API to allow the module to receive notifications when defrag start and end: `RM_RegisterDefragCallbacks`
      Those callbacks are the same as `RM_RegisterDefragFunc` but promised to be called and the start
      and the end of the defrag process.
      d3d94ccf
    • Filipe Oliveira (Redis)'s avatar
      Created specific SMEMBERS command logic which avoids sinterGenericCommand, and... · 00a8e72c
      Filipe Oliveira (Redis) authored
      
      Created specific SMEMBERS command logic which avoids sinterGenericCommand, and minimizes processing and memory overhead (#13499)
      
      This PR introduces a dedicated implementation for the SMEMBERS command
      that avoids using the more generalized sinterGenericCommand function.
      By tailoring the logic specifically for SMEMBERS, we reduce unnecessary
      processing and memory overheads that were previously incurred by
      handling more complex cases like set intersections.
      
      ---------
      Co-authored-by: default avatardebing.sun <debing.sun@redis.com>
      00a8e72c
    • Filipe Oliveira (Redis)'s avatar
      Optimize the HELLO command reply (#13490) · a31b516e
      Filipe Oliveira (Redis) authored
      # Overall improvement
      
      TBD ( current is approximately 6% on the achievable ops/sec), coming
      from:
      
      - In case of no module we can skip 1.3% CPU cycles on dict Iterator
      creation/deletion
      - Use addReplyBulkCBuffer instead of addReplyBulkCString to avoid
      runtime strlen overhead within HELLO reply on string constants.
      
      ## Optimization 1: In case of no module we can skip 1.3% CPU cycles on
      dict Iterator creation/deletion.
      
      ## Optimization 2: Use addReplyBulkCBuffer instead of
      addReplyBulkCString to avoid runtime strlen overhead within HELLO reply
      on string constants.
      a31b516e
    • cyy-tag's avatar
      Fixed variable parameter formatting issues in serverPanic function (#13504) · c77b8f45
      cyy-tag authored
      
      
      Currently aeApiPoll panic does not record error code information. Added
      variable parameter formatting to _serverPanic to fix the issue
      
      ---------
      Co-authored-by: default avataryingyin.chen <15816602944@163.com>
      c77b8f45
    • Ozan Tezcan's avatar
      Reply LOADING on replica while flushing the db (#13495) · a7afd1d2
      Ozan Tezcan authored
      On a full sync, replica starts discarding existing db. If the existing 
      db is huge and flush is happening synchronously, replica may become 
      unresponsive. 
      
      Adding a change to yield back to event loop while flushing db on 
      a replica. Replica will reply -LOADING in this case. Note that while 
      replica is loading the new rdb, it may get an error and start flushing
      the partial db. This step may take a long time as well. Similarly, 
      replica will reply -LOADING in this case. 
      
      To call processEventsWhileBlocked() and reply -LOADING, we need to do:
      - Set connSetReadHandler() null not to process further data from the master
      - Set server.loading flag
      - Call blockingOperationStarts()
      
      rdbload() already does these steps and calls processEventsWhileBlocked()
      while loading the rdb. Added a new call rdbLoadWithEmptyFunc() which 
      accepts callback to flush db before loading rdb or when an error 
      happens while loading. 
      
      For diskless replication, doing something similar and calling emptyData()
      after setting required flags.
      
      Additional changes:
      - Allow `appendonly` config change during loading. 
       Config can be changed while loading data on startup or on replication 
       when slave is loading RDB. We allow config change command to update 
       `server.aof_enabled` and then lazily apply config change after loading
       operation is completed.
       
       - Added a test for `replica-lazy-flush` config
      a7afd1d2
  10. 29 Aug, 2024 1 commit
    • Oran Agra's avatar
      testsuite --dump-logs works on servers started before the test (#13500) · 3fcddfb6
      Oran Agra authored
      so far ./runtest --dump-logs used work for servers started within the
      test proc.
      now it'll also work on servers started outside the test proc scope.
      the downside is that these logs can be huge if they served many tests
      and not just the failing one.
      but for some rare failures, we rather have that than nothing.
      this feature isn't enabled y default, but is used by our GH actions.
      3fcddfb6
  11. 28 Aug, 2024 1 commit
  12. 26 Aug, 2024 1 commit
  13. 21 Aug, 2024 1 commit
  14. 20 Aug, 2024 2 commits
    • Zihao Lin's avatar
      Improve GETRANGE command behavior (#12272) · 6ceadfb5
      Zihao Lin authored
      
      
      Fixed the issue about GETRANGE and SUBSTR command
      return unexpected result caused by the `start` and `end` out of
      definition range of string.
      
      ---
      ## break change
      Before this PR, when negative `end` was out of range (i.e., end <
      -strlen), we would fix it to 0 to get the substring, which also resulted
      in the first character still being returned for this kind of out of
      range.
      After this PR, we ensure that `GETRANGE` returns an empty bulk when the
      negative end index is out of range.
      
      Closes #11738
      
      ---------
      Co-authored-by: default avatardebing.sun <debing.sun@redis.com>
      6ceadfb5
    • judeng's avatar
      improve performance for scan command when matching data type (#12395) · 7f0a7f0a
      judeng authored
      Move the TYPE filtering to the scan callback so that avoided the
      `lookupKey` operation. This is the follow-up to #12209 . In this thread
      we introduced two breaking changes:
      1. we will not attempt to do lazy expire (delete) a key that was
      filtered by not matching the TYPE (like we already do for MATCH
      pattern).
      2. when the specified key TYPE filter is an unknown type, server will
      reply a error immediately instead of doing a full scan that comes back
      empty handed.
      7f0a7f0a
  15. 19 Aug, 2024 2 commits
    • Meir Shpilraien (Spielrein)'s avatar
      Avoid used_memory contention when update from multiple threads. (#13431) · 3264deb2
      Meir Shpilraien (Spielrein) authored
      The PR attempt to avoid contention on the `used_memory` global variable
      when allocate or free memory from multiple threads at the same time.
      
      Each time a thread is allocating or releasing a memory, it needs to
      update the `used_memory` global variable. This update might cause a
      contention when done aggressively from multiple threads.
      
      ### The solution
      
      Instead of having a single global variable that need to be updated from
      multiple thread. We create an array of used_memory, each entry in the
      array is updated by a single thread and the main thread summarizes all
      the values to accumulate the memory usage.
      
      This solution, though reduces the contention between threads on updating
      the `used_memory` global variable, it adds work to the main thread that
      need to summarize all the entries at the `used_memory` array. To avoid
      increasing the work done by the main thread by too much, we limit the
      size of the used memory array to 16. This means that up to 16 threads
      can run without any contention between them. If there are more than 16
      threads, we will reuse entries on the used_memory array, in this case we
      might still have contention between threads, but it will be much less
      significant.
      
      Notice, that in order to really avoid contention, the entries in the
      `used_memory` array must reside on different cache lines. To achieve
      that we create a struct with padding such that its size will be exactly
      cache_line size. In addition we make sure the address of the
      `used_memory` array will be aligned to cache_line size.
      
      ### Benchmark
      
      Some benchmark shows improvement (up to 15%):
      
      | Test Case |Baseline unstable (median obs. +- std.dev)|Comparison
      test_used_memory_per_thread_array (median obs. +- std.dev)|% change
      (higher-better)| Note |
      
      |-------------------------------------------------------------------------------|------------------------------------------|--------------------------------------------------------------------:|------------------------|------------------------------------|
      |memtier_benchmark-1key-list-100-elements-lrange-all-elements | 92657 +-
      2.0% (2 datapoints) | 101445|9.5% |IMPROVEMENT |
      |memtier_benchmark-1key-list-1K-elements-lrange-all-elements | 14965 +-
      1.3% (2 datapoints) | 16296|8.9% |IMPROVEMENT |
      |memtier_benchmark-1key-set-10-elements-smembers-pipeline-10 | 431019 +-
      5.2% (2 datapoints) | 461039|7.0% |waterline=5.2%. IMPROVEMENT |
      |memtier_benchmark-1key-set-100-elements-smembers | 74367 +- 0.0% (2
      datapoints) | 80190|7.8% |IMPROVEMENT |
      |memtier_benchmark-1key-set-1K-elements-smembers | 11730 +- 0.4% (2
      datapoints) | 13519|15.3% |IMPROVEMENT |
      
      
      Full results:
      
      | Test Case |Baseline unstable (median obs. +- std.dev)|Comparison
      test_used_memory_per_thread_array (median obs. +- std.dev)|% change
      (higher-better)| Note |
      
      |-------------------------------------------------------------------------------|------------------------------------------|--------------------------------------------------------------------:|------------------------|------------------------------------|
      |memtier_benchmark-10Mkeys-load-hash-5-fields-with-1000B-values | 88613
      +- 1.0% (2 datapoints) | 88688|0.1% |No Change |
      
      |memtier_benchmark-10Mkeys-load-hash-5-fields-with-1000B-values-pipeline-10
      | 124786 +- 1.2% (2 datapoints) | 123671|-0.9% |No Change |
      |memtier_benchmark-10Mkeys-load-hash-5-fields-with-100B-values | 122460
      +- 1.4% (2 datapoints) | 122990|0.4% |No Change |
      
      |memtier_benchmark-10Mkeys-load-hash-5-fields-with-100B-values-pipeline-10
      | 333384 +- 5.1% (2 datapoints) | 319221|-4.2% |waterline=5.1%.
      potential REGRESSION|
      |memtier_benchmark-10Mkeys-load-hash-5-fields-with-10B-values | 137354
      +- 0.3% (2 datapoints) | 138759|1.0% |No Change |
      
      |memtier_benchmark-10Mkeys-load-hash-5-fields-with-10B-values-pipeline-10
      | 401261 +- 4.3% (2 datapoints) | 398524|-0.7% |No Change |
      |memtier_benchmark-1Mkeys-100B-expire-use-case | 179058 +- 0.4% (2
      datapoints) | 180114|0.6% |No Change |
      |memtier_benchmark-1Mkeys-10B-expire-use-case | 180390 +- 0.2% (2
      datapoints) | 180401|0.0% |No Change |
      |memtier_benchmark-1Mkeys-1KiB-expire-use-case | 175993 +- 0.7% (2
      datapoints) | 175147|-0.5% |No Change |
      |memtier_benchmark-1Mkeys-4KiB-expire-use-case | 165771 +- 0.0% (2
      datapoints) | 164434|-0.8% |No Change |
      |memtier_benchmark-1Mkeys-bitmap-getbit-pipeline-10 | 931339 +- 2.1% (2
      datapoints) | 929487|-0.2% |No Change |
      |memtier_benchmark-1Mkeys-generic-exists-pipeline-10 | 999462 +- 0.4% (2
      datapoints) | 963226|-3.6% |potential REGRESSION |
      |memtier_benchmark-1Mkeys-generic-expire-pipeline-10 | 905333 +- 1.4% (2
      datapoints) | 896673|-1.0% |No Change |
      |memtier_benchmark-1Mkeys-generic-expireat-pipeline-10 | 885015 +- 1.0%
      (2 datapoints) | 865010|-2.3% |No Change |
      |memtier_benchmark-1Mkeys-generic-pexpire-pipeline-10 | 897115 +- 1.2%
      (2 datapoints) | 887544|-1.1% |No Change |
      |memtier_benchmark-1Mkeys-generic-scan-pipeline-10 | 451103 +- 3.2% (2
      datapoints) | 465571|3.2% |potential IMPROVEMENT |
      |memtier_benchmark-1Mkeys-generic-touch-pipeline-10 | 996809 +- 0.6% (2
      datapoints) | 984478|-1.2% |No Change |
      |memtier_benchmark-1Mkeys-generic-ttl-pipeline-10 | 979570 +- 1.7% (2
      datapoints) | 958752|-2.1% |No Change |
      
      |memtier_benchmark-1Mkeys-hash-hget-hgetall-hkeys-hvals-with-100B-values
      | 180888 +- 0.5% (2 datapoints) | 182295|0.8% |No Change |
      
      |memtier_benchmark-1Mkeys-hash-hmget-5-fields-with-100B-values-pipeline-10
      | 717881 +- 1.0% (2 datapoints) | 724814|1.0% |No Change |
      |memtier_benchmark-1Mkeys-hash-transactions-multi-exec-pipeline-20 |
      1055447 +- 0.4% (2 datapoints) | 1065836|1.0% |No Change |
      |memtier_benchmark-1Mkeys-lhash-hexists | 164332 +- 0.1% (2 datapoints)
      | 163636|-0.4% |No Change |
      |memtier_benchmark-1Mkeys-lhash-hincbry | 171674 +- 0.3% (2 datapoints)
      | 172737|0.6% |No Change |
      |memtier_benchmark-1Mkeys-list-lpop-rpop-with-100B-values | 180904 +-
      1.1% (2 datapoints) | 179467|-0.8% |No Change |
      |memtier_benchmark-1Mkeys-list-lpop-rpop-with-10B-values | 181746 +-
      0.8% (2 datapoints) | 182416|0.4% |No Change |
      |memtier_benchmark-1Mkeys-list-lpop-rpop-with-1KiB-values | 182004 +-
      0.7% (2 datapoints) | 180237|-1.0% |No Change |
      |memtier_benchmark-1Mkeys-load-hash-5-fields-with-1000B-values | 105191
      +- 0.9% (2 datapoints) | 105058|-0.1% |No Change |
      
      |memtier_benchmark-1Mkeys-load-hash-5-fields-with-1000B-values-pipeline-10
      | 150683 +- 0.9% (2 datapoints) | 153597|1.9% |No Change |
      |memtier_benchmark-1Mkeys-load-hash-hmset-5-fields-with-1000B-values |
      104122 +- 0.7% (2 datapoints) | 105236|1.1% |No Change |
      |memtier_benchmark-1Mkeys-load-list-with-100B-values | 149770 +- 0.9% (2
      datapoints) | 150510|0.5% |No Change |
      |memtier_benchmark-1Mkeys-load-list-with-10B-values | 165537 +- 1.9% (2
      datapoints) | 164329|-0.7% |No Change |
      |memtier_benchmark-1Mkeys-load-list-with-1KiB-values | 113315 +- 0.5% (2
      datapoints) | 114110|0.7% |No Change |
      |memtier_benchmark-1Mkeys-load-stream-1-fields-with-100B-values | 131201
      +- 0.7% (2 datapoints) | 129545|-1.3% |No Change |
      
      |memtier_benchmark-1Mkeys-load-stream-1-fields-with-100B-values-pipeline-10
      | 352891 +- 2.8% (2 datapoints) | 348338|-1.3% |No Change |
      |memtier_benchmark-1Mkeys-load-stream-5-fields-with-100B-values | 104386
      +- 0.7% (2 datapoints) | 105796|1.4% |No Change |
      
      |memtier_benchmark-1Mkeys-load-stream-5-fields-with-100B-values-pipeline-10
      | 227593 +- 5.5% (2 datapoints) | 218783|-3.9% |waterline=5.5%.
      potential REGRESSION|
      |memtier_benchmark-1Mkeys-load-string-with-100B-values | 167552 +- 0.2%
      (2 datapoints) | 170282|1.6% |No Change |
      |memtier_benchmark-1Mkeys-load-string-with-100B-values-pipeline-10 |
      646888 +- 0.5% (2 datapoints) | 639680|-1.1% |No Change |
      |memtier_benchmark-1Mkeys-load-string-with-10B-values | 174891 +- 0.7%
      (2 datapoints) | 174382|-0.3% |No Change |
      |memtier_benchmark-1Mkeys-load-string-with-10B-values-pipeline-10 |
      749988 +- 5.1% (2 datapoints) | 769986|2.7% |waterline=5.1%. No Change |
      |memtier_benchmark-1Mkeys-load-string-with-1KiB-values | 155929 +- 0.1%
      (2 datapoints) | 156387|0.3% |No Change |
      |memtier_benchmark-1Mkeys-load-zset-with-10-elements-double-score |
      92241 +- 0.2% (2 datapoints) | 92189|-0.1% |No Change |
      |memtier_benchmark-1Mkeys-load-zset-with-10-elements-int-score | 114328
      +- 1.3% (2 datapoints) | 113154|-1.0% |No Change |
      |memtier_benchmark-1Mkeys-string-get-100B | 180685 +- 0.2% (2
      datapoints) | 180359|-0.2% |No Change |
      |memtier_benchmark-1Mkeys-string-get-100B-pipeline-10 | 991291 +- 3.1%
      (2 datapoints) | 1020086|2.9% |No Change |
      |memtier_benchmark-1Mkeys-string-get-10B | 181183 +- 0.3% (2 datapoints)
      | 177868|-1.8% |No Change |
      |memtier_benchmark-1Mkeys-string-get-10B-pipeline-10 | 1032554 +- 0.8%
      (2 datapoints) | 1023120|-0.9% |No Change |
      |memtier_benchmark-1Mkeys-string-get-1KiB | 180479 +- 0.9% (2
      datapoints) | 182215|1.0% |No Change |
      |memtier_benchmark-1Mkeys-string-get-1KiB-pipeline-10 | 979286 +- 0.9%
      (2 datapoints) | 989888|1.1% |No Change |
      |memtier_benchmark-1Mkeys-string-mget-1KiB | 121950 +- 0.4% (2
      datapoints) | 120996|-0.8% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geodist | 179404 +- 1.0% (2
      datapoints) | 181232|1.0% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geodist-pipeline-10 | 1023797
      +- 0.5% (2 datapoints) | 1014980|-0.9% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geohash | 180808 +- 1.2% (2
      datapoints) | 180606|-0.1% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geohash-pipeline-10 | 1056458
      +- 1.6% (2 datapoints) | 1040050|-1.6% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geopos | 181808 +- 0.2% (2
      datapoints) | 175945|-3.2% |potential REGRESSION |
      |memtier_benchmark-1key-geo-60M-elements-geopos-pipeline-10 | 1038180 +-
      3.4% (2 datapoints) | 1033005|-0.5% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geosearch-fromlonlat | 142614
      +- 0.3% (2 datapoints) | 144259|1.2% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geosearch-fromlonlat-bybox |
      141008 +- 0.4% (2 datapoints) | 139602|-1.0% |No Change |
      
      |memtier_benchmark-1key-geo-60M-elements-geosearch-fromlonlat-pipeline-10
      | 560698 +- 0.8% (2 datapoints) | 548806|-2.1% |No Change |
      |memtier_benchmark-1key-list-10-elements-lrange-all-elements | 166132 +-
      0.9% (2 datapoints) | 170259|2.5% |No Change |
      |memtier_benchmark-1key-list-100-elements-lrange-all-elements | 92657 +-
      2.0% (2 datapoints) | 101445|9.5% |IMPROVEMENT |
      |memtier_benchmark-1key-list-1K-elements-lrange-all-elements | 14965 +-
      1.3% (2 datapoints) | 16296|8.9% |IMPROVEMENT |
      |memtier_benchmark-1key-pfadd-4KB-values-pipeline-10 | 264156 +- 0.2% (2
      datapoints) | 262582|-0.6% |No Change |
      |memtier_benchmark-1key-set-10-elements-smembers | 138916 +- 1.7% (2
      datapoints) | 138016|-0.6% |No Change |
      |memtier_benchmark-1key-set-10-elements-smembers-pipeline-10 | 431019 +-
      5.2% (2 datapoints) | 461039|7.0% |waterline=5.2%. IMPROVEMENT |
      |memtier_benchmark-1key-set-10-elements-smismember | 173545 +- 1.1% (2
      datapoints) | 173488|-0.0% |No Change |
      |memtier_benchmark-1key-set-100-elements-smembers | 74367 +- 0.0% (2
      datapoints) | 80190|7.8% |IMPROVEMENT |
      |memtier_benchmark-1key-set-100-elements-smismember | 155682 +- 1.6% (2
      datapoints) | 151367|-2.8% |No Change |
      |memtier_benchmark-1key-set-1K-elements-smembers | 11730 +- 0.4% (2
      datapoints) | 13519|15.3% |IMPROVEMENT |
      |memtier_benchmark-1key-set-200K-elements-sadd-constant | 181070 +- 1.1%
      (2 datapoints) | 180214|-0.5% |No Change |
      |memtier_benchmark-1key-set-2M-elements-sadd-increasing | 166364 +- 0.1%
      (2 datapoints) | 166944|0.3% |No Change |
      |memtier_benchmark-1key-zincrby-1M-elements-pipeline-1 | 46071 +- 0.6%
      (2 datapoints) | 44979|-2.4% |No Change |
      |memtier_benchmark-1key-zrank-1M-elements-pipeline-1 | 48429 +- 0.4% (2
      datapoints) | 49265|1.7% |No Change |
      |memtier_benchmark-1key-zrem-5M-elements-pipeline-1 | 48528 +- 0.4% (2
      datapoints) | 48869|0.7% |No Change |
      |memtier_benchmark-1key-zrevrangebyscore-256K-elements-pipeline-1 |
      100580 +- 1.5% (2 datapoints) | 101782|1.2% |No Change |
      |memtier_benchmark-1key-zrevrank-1M-elements-pipeline-1 | 48621 +- 2.0%
      (2 datapoints) | 48473|-0.3% |No Change |
      |memtier_benchmark-1key-zset-10-elements-zrange-all-elements | 83485 +-
      0.6% (2 datapoints) | 83095|-0.5% |No Change |
      
      |memtier_benchmark-1key-zset-10-elements-zrange-all-elements-long-scores
      | 118673 +- 0.8% (2 datapoints) | 118006|-0.6% |No Change |
      |memtier_benchmark-1key-zset-100-elements-zrange-all-elements | 19009 +-
      1.1% (2 datapoints) | 19293|1.5% |No Change |
      |memtier_benchmark-1key-zset-100-elements-zrangebyscore-all-elements |
      18957 +- 0.5% (2 datapoints) | 19419|2.4% |No Change |
      
      |memtier_benchmark-1key-zset-100-elements-zrangebyscore-all-elements-long-scores|
      171693 +- 0.5% (2 datapoints) | 172432|0.4% |No Change |
      |memtier_benchmark-1key-zset-1K-elements-zrange-all-elements | 3566 +-
      0.6% (2 datapoints) | 3672|3.0% |No Change |
      |memtier_benchmark-1key-zset-1M-elements-zcard-pipeline-10 | 1067713 +-
      0.4% (2 datapoints) | 1071550|0.4% |No Change |
      |memtier_benchmark-1key-zset-1M-elements-zrevrange-5-elements | 169195
      +- 0.7% (2 datapoints) | 169620|0.3% |No Change |
      |memtier_benchmark-1key-zset-1M-elements-zscore-pipeline-10 | 914338 +-
      0.2% (2 datapoints) | 905540|-1.0% |No Change |
      |memtier_benchmark-2keys-lua-eval-hset-expire | 88346 +- 1.7% (2
      datapoints) | 87259|-1.2% |No Change |
      |memtier_benchmark-2keys-lua-evalsha-hset-expire | 103273 +- 1.2% (2
      datapoints) | 102393|-0.9% |No Change |
      |memtier_benchmark-2keys-set-10-100-elements-sdiff | 15418 +- 10.9%
      UNSTABLE (2 datapoints) | 14369|-6.8% |UNSTABLE (very high variance) |
      |memtier_benchmark-2keys-set-10-100-elements-sinter | 83601 +- 3.6% (2
      datapoints) | 82508|-1.3% |No Change |
      |memtier_benchmark-2keys-set-10-100-elements-sunion | 14942 +- 11.2%
      UNSTABLE (2 datapoints) | 14001|-6.3% |UNSTABLE (very high variance) |
      |memtier_benchmark-2keys-stream-5-entries-xread-all-entries | 75938 +-
      0.4% (2 datapoints) | 76565|0.8% |No Change |
      |memtier_benchmark-2keys-stream-5-entries-xread-all-entries-pipeline-10
      | 120781 +- 1.1% (2 datapoints) | 119142|-1.4% |No Change |
      3264deb2
    • debing.sun's avatar
      Fix a race condition issue in the cache_memory of functionsLibCtx (#13476) · 6c648928
      debing.sun authored
      This is a missing of the PR https://github.com/redis/redis/pull/13383.
      We will call `functionsLibCtxClear()` in bio, so we shouldn't touch
      `curr_functions_lib_ctx` in it.
      6c648928
  16. 16 Aug, 2024 1 commit
    • debing.sun's avatar
      Fix incorrect lag due to trimming stream via XTRIM command (#13473) · 2b88db90
      debing.sun authored
      ## Describe
      When using the `XTRIM` command to trim a stream, it does not update the
      maximal tombstone (`max_deleted_entry_id`). This leads to an issue where
      the lag calculation incorrectly assumes that there are no tombstones
      after the consumer group's last_id, resulting in an inaccurate lag.
      
      The reason XTRIM doesn't need to update the maximal tombstone is that it
      always trims from the beginning of the stream. This means that it
      consistently changes the position of the first entry, leading to the
      following scenarios:
      
      1) First entry trimmed after maximal tombstone:
      If the first entry is trimmed to a position after the maximal tombstone,
      all tombstones will be before the first entry, so they won't affect the
      consumer group's lag.
      
      2) First entry trimmed before maximal tombstone:
      If the first entry is trimmed to a position before the maximal
      tombstone, the maximal tombstone will not be updated.
      
      ## Solution
      Therefore, this PR optimizes the lag calculation by ensuring that when
      both the consumer group's last_id and the maximal tombstone are behind
      the first entry, the consumer group's lag is always equal to the number
      of remaining elements in the stream.
      
      Supplement to PR https://github.com/redis/redis/pull/13338
      2b88db90
  17. 14 Aug, 2024 1 commit
  18. 11 Aug, 2024 1 commit
    • Moti Cohen's avatar
      On HDEL last field with expiry, update global HFE DS (#13470) · 806459f4
      Moti Cohen authored
      Hash field expiration is optimized to avoid frequent update global HFE DS for
      each field deletion. Eventually active-expiration will run and update or remove
      the hash from global HFE DS gracefully. Nevertheless, statistic "subexpiry"
      might reflect wrong number of hashes with HFE to the user if HDEL deletes
      the last field with expiration in hash (yet there are more fields without expiration).
      
      Following this change, if HDEL the last field with expiration in the hash then
      take care to remove the hash from global HFE DS as well.
      806459f4
  19. 08 Aug, 2024 2 commits
  20. 06 Aug, 2024 2 commits
  21. 05 Aug, 2024 4 commits
    • YaacovHazan's avatar
      Keep cluster shards command implementation generic (#13440) · e4ddc344
      YaacovHazan authored
      Make the clusterCommandShards function use only cluster API functions
      instead of accessing cluster implementation details.
      This way the cluster API implementation doesn't have to have intimate
      knowledge of the command reply format, and doesn't need to interact with
      the client directly (the addReply function family).
      The PR has two commits, one moves the function from cluster_legacy.c to
      cluster.c, and the other modifies it's implementation.
      
      
      **better merge without squashing.**
      e4ddc344
    • Josh Hershberg's avatar
      Make cluster shards cmd implementation generic · 6d5d7541
      Josh Hershberg authored
      
      
      This and the previous commit make the cluster
      shards command a generic implementation instead of a
      specific implementation for each cluster API implementation.
      This commit (a) adds functions to the cluster API
      and (b) modifies the cluster shards cmd implementation
      to use cluster API functions instead of directly
      accessing the legacy clustering implementation.
      Signed-off-by: default avatarJosh Hershberg <yehoshua@redis.com>
      6d5d7541
    • Josh Hershberg's avatar
      Prep to make cluster shards cmd generic · e3e631f3
      Josh Hershberg authored
      
      
      This and the next following commit makes the cluster
      shards command a generic implementation instead of a
      specific implementation for each cluster API implementation.
      This commit simply moves the cluster shards implementation
      from cluster_legacy.c to cluster.c without changing the
      implementation at all. The reason for doing so was to
      help with reviewing the changes in the diff.
      Signed-off-by: default avatarJosh Hershberg <yehoshua@redis.com>
      e3e631f3
    • Zhongxian Pan's avatar
      Replace bit shift with __builtin_ctzll in HyperLogLog (#13218) · 6263823e
      Zhongxian Pan authored
      
      
      ## Replace bit shift with `__builtin_ctzll` in HyperLogLog
      
      Builtin function `__builtin_ctzll` is more effective than bit shift even
      though "in the average case there are high probabilities to find a 1
      after a few iterations" mentioned in the source file comment.
      
      ---------
      Co-authored-by: default avatardebing.sun <debing.sun@redis.com>
      6263823e