Redis 벤치마크 매개변수를 확인하는 방법

Redis에는 N개의 클라이언트가 동시에 M개의 요청을 보내는 것을 시뮬레이션하는 redis-benchmark라는 도구가 함께 제공됩니다. (Apacheb 프로그램과 유사) 벤치마크 매개변수를 보려면 redis-benchmark -h 명령을 사용하세요.

以下参数被支持：

    Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests> [-k <boolean>]

     -h <hostname>      Server hostname (default 127.0.0.1)
     -p <port>          Server port (default 6379)
     -s <socket>        Server socket (overrides host and port)
     -c <clients>       Number of parallel connections (default 50)
     -n <requests>      Total number of requests (default 10000)
     -d <size>          Data size of SET/GET value in bytes (default 2)
     -k <boolean>       1=keep alive 0=reconnect (default 1)
     -r <keyspacelen>   Use random keys for SET/GET/INCR, random values for SADD
      Using this option the benchmark will get/set keys
      in the form mykey_rand:000000012456 instead of constant
      keys, the <keyspacelen> argument determines the max
      number of values for the random number. For instance
      if set to 10 only rand:000000000000 - rand:000000000009
      range will be allowed.
     -P <numreq>        Pipeline <numreq> requests. Default 1 (no pipeline).
     -q                 Quiet. Just show query/sec values
     --csv              Output in CSV format
     -l                 Loop. Run the tests forever
     -t <tests>         Only run the comma separated list of tests. The test
                        names are the same as the ones produced as output.
     -I                 Idle mode. Just open N idle connections and wait.</tests></numreq></numreq></keyspacelen></keyspacelen></boolean></size></requests></clients></socket></port></hostname></boolean></requests></clients></port></host>

벤치마킹하기 전에 Redis 인스턴스를 시작해야 합니다. 일반적으로 테스트는 다음과 같이 시작됩니다.

redis-benchmark -q -n 100000

이 도구는 사용하기 매우 편리하며 자체 벤치마크 테스트 도구를 사용할 수 있습니다. 그러나 벤치마크 테스트를 시작할 때 몇 가지 세부 사항에 주의해야 합니다.

일부 테스트 사례의 하위 집합만 실행

redis-benchmark를 실행할 때마다 기본적으로 모든 테스트를 실행하지 마세요. "-t" 매개변수를 사용하여 다음 예와 같이 실행해야 하는 테스트 사례를 지정할 수 있습니다.

$ redis-benchmark -t set,lpush -n 100000 -q
SET: 74239.05 requests per second
LPUSH: 79239.30 requests per second

위 테스트에서는 SET 및 LPUSH 명령만 실행하고 자동 모드에서 실행했습니다( -q 매개변수).

다음 예와 같이 직접 실행할 명령을 직접 지정할 수도 있습니다.

$ redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"
script load redis.call('set','foo','bar'): 69881.20 requests per second

테스트 키의 범위 크기 선택

기본적으로 벤치마크 테스트에서는 단일 키를 사용합니다. 인메모리 데이터베이스에서는 단일 키 테스트와 실제 세계 사이에 큰 차이가 없습니다. 물론 키 범위를 넓히면 실제 캐시 누락을 시뮬레이션할 수 있습니다.

이때 -r 명령을 사용할 수 있습니다. 예를 들어, 매번 100,000개의 임의 키를 사용하여 100만 개의 SET 작업을 연속적으로 수행하려면 다음 명령을 사용할 수 있습니다.

$ redis-cli flushall
OK

$ redis-benchmark -t set -r 100000 -n 1000000
====== SET ======
  1000000 requests completed in 13.86 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.76% `<h3>파이프라이닝 사용</h3><p>기본적으로 각 클라이언트는 다음 요청이 완료될 때까지 기다립니다. 요청(-c로 특정 숫자를 지정하지 않는 한 벤치마크는 50개의 클라이언트를 시뮬레이션합니다). 이는 서버가 각 클라이언트의 명령을 거의 순차적으로 읽는다는 의미입니다. 또한 RTT도 지급됩니다.</p><p>Redis는 /topics/pipelining을 지원하므로 한 번에 여러 명령을 실행할 수 있습니다. Redis 파이프라이닝을 사용하여 서버의 초당 트랜잭션 속도를 높이세요. </p><p>다음 사례는 Macbook air 11"에서 파이프라이닝을 사용하여 16개의 명령을 정리한 테스트 예입니다. </p><pre class="brush:php;toolbar:false">$ redis-benchmark -n 1000000 -t set,get -P 16 -q
SET: 403063.28 requests per second
GET: 508388.41 requests per second

여러 명령을 처리해야 하는 경우 파이프라이닝을 사용하는 것을 잊지 마세요.

트랩과 오해

첫 번째 요점은 명백합니다. : 벤치마크 테스트의 황금률은 동일한 표준을 사용하는 것입니다. 서로 다른 버전의 Redis를 테스트할 때 동일한 워크로드로 테스트할 수도 있고, 다른 도구로 Redis를 테스트할 경우 차이점에 주의해야 합니다.

• Redis는 서버입니다. 모든 명령에는 네트워크 또는 IPC 오버헤드가 포함됩니다. 즉, SQLite, Berkeley DB, Tokyo/Kyoto Cabinet 등과 비교하는 것은 의미가 없습니다.

• Redis의 가장 일반적인 명령에는 확인 반환이 있습니다. 예를 들어 MongoDB의 쓰기 작업은 확인을 반환하지 않지만 일부 데이터 저장 시스템은 확인을 반환합니다.

• Redis의 간단한 루프 작업은 실제로 Redis의 벤치마크 테스트가 아니라 네트워크(또는 IPC) 대기 시간을 테스트하는 것입니다. Redis와 같은 여러 연결을 사용해야 합니다. 벤치마크) 또는 파이프라이닝을 사용하여 다중 명령을 집계할 수도 있습니다.

• Redis는 메모리 내 데이터베이스이며 지속성과 함께 사용하려는 경우 몇 가지 선택적 지속성 기능을 제공합니다. 서버(MySQL, PostgreSQL 등))을 사용하는 경우 AOF 및 적절한 fsync 전략을 고려해야 합니다.

• Redis는 다중 CPU에 최적화되도록 설계되지 않았으므로 다중 CPU를 활성화하는 것은 불공평합니다. 단일 인스턴스 Redis를 다중 스레드 데이터베이스와 비교하세요.

redis-benchmark가 의도적으로 벤치마크를 더 좋게 만들고 표시되는 데이터가 실제 제품보다 인위적으로 보인다는 오해가 있습니다.

Redis-benchmark. 도구는 특정 하드웨어 조건에서 머신의 성능 매개변수를 빠르고 쉽게 계산할 수 있지만 이는 일반적으로 파이프라인을 사용하여 달성할 수 있는 최대 처리량은 아니며 클라이언트(예: Hiredis)는 기본적으로 더 높은 처리량을 달성할 수 있습니다. redis-benchmark는 처리량을 향상시키기 위해 동시성을 사용합니다(다중 연결 생성). 파이프라이닝이나 기타 동시성 기술을 사용하지 않고 다중 스레딩이 아닌 다중 연결을 사용합니다.

더 높은 처리량을 달성하기 위해 벤치마킹에 파이프라이닝 모드를 사용하려는 경우 -P 매개변수를 사용할 수 있습니다. 프로덕션 환경에서 Redis를 사용하는 많은 애플리케이션은 성능 향상을 위해 이 접근 방식을 채택합니다.

마지막으로 벤치마크 테스트는 비교를 위해 동일한 연산과 데이터를 사용해야 합니다. 이것이 동일하지 않으면 벤치마크 테스트는 의미가 없습니다.

예를 들어 Redis와 memcached는 단일 스레드 모드에서 GET/SET 작업을 비교할 수 있습니다. 둘 다 인메모리 데이터베이스이며 프로토콜은 기본적으로 동일합니다. 여러 요청을 하나의 요청으로 병합하는 방식도 비슷합니다(파이프라이닝). 이 비교는 동일한 수의 연결을 사용한 후에 의미가 있습니다.

다음은 Redis(antirez)와 memcached(dormando)에서 테스트한 훌륭한 예입니다.

antirez 1 - Redis, Memcached, Speed, Benchmarks 및 The Bathroom

dormando - Redis VS Memcached(약간 더 나은 벤치)

antirez 2 - Memcached/Redis 벤치마크에 대한 업데이트

아래에서 최종 결과를 확인할 수 있습니다. 동일한 조건 둘 사이에는 큰 차이가 없습니다. 최종 테스트 당시 두 가지 모두 완전히 최적화되었습니다.

마지막으로 특히 고성능 서버(예: Redis, memcached 등)를 벤치마킹할 때 서버 성능을 최대한 활용하기 어렵습니다. 일반적으로 병목 현상은 서버 측이 아닌 클라이언트 측에서 발생합니다. 이 경우 최대 처리량을 달성하려면 클라이언트(예: 벤치마크 프로그램 자체)를 최적화하거나 여러 인스턴스를 사용해야 합니다.

Redis 성능에 영향을 미치는 요소

Redis 성능을 직접적으로 결정하는 몇 가지 요소가 있습니다. 이는 벤치마크 결과를 변경할 수 있으므로 주의를 기울여야 합니다. 일반적으로 Redis의 기본 매개변수는 효율적인 성능을 제공하기에 충분하므로 튜닝이 필요하지 않습니다.

• 네트워크 대역폭과 대기 시간은 일반적으로 가장 큰 단점입니다. 벤치마킹하기 전에 ping 명령을 사용하여 서버와 클라이언트 간의 대기 시간을 감지하는 것이 좋습니다. 대역폭을 기준으로 최대 처리량을 계산할 수 있습니다. 예를 들어 4KB 문자열이 Redis에 삽입되고 처리량이 100,000q/s인 경우 실제로 3.2Gbits/s의 대역폭이 필요하므로 10GBits/s 네트워크 연결로는 충분하지 않습니다. . 많은 온라인 서비스에서 네트워크 대역폭은 CPU보다 먼저 Redis 처리량의 제한 요소가 되는 경우가 많습니다. 높은 처리량을 달성하고 TCP/IP 제한을 극복하기 위해 최종적으로 10Gbits/s 네트워크 카드 또는 여러 개의 1Gbits/s 네트워크 카드가 사용됩니다.

• CPU는 단일 스레드 모델이기 때문에 멀티 코어 대신 대용량 캐시와 빠른 CPU를 선호합니다. 이 시나리오에서는 Intel CPU가 더 권장됩니다. AMD CPU는 아마도 Intel CPU의 절반 수준일 것입니다(Nehalem EP/Westmere EP/Sandy 플랫폼과 비교). 다른 조건이 동일하면 CPU가 redis-benchmark의 병목 현상이 됩니다.

• 작은 개체에 액세스할 때는 메모리 속도와 대역폭이 그다지 중요하지 않은 것 같지만, 큰 개체(10KB 이상)의 경우 중요해집니다. 일반적으로 사람들은 Redis를 최적화하기 위해 고성능 메모리 모듈을 구입하지 않습니다.

• Redis는 VM에서 느려집니다. 가상화는 일반 작업에 추가 소비를 가져오는 반면 Redis는 시스템 호출 및 네트워크 터미널에 많은 오버헤드를 갖지 않습니다. 지연 시간이 특히 우려되는 경우 Redis를 배포하고 물리적 서버에서 실행하는 것이 좋습니다. 가장 발전된 가상화 장치(VMware)에서 redis-benchmark의 테스트 결과는 실제 머신보다 2배 느리고, 시스템 호출 및 인터럽트에 CPU 시간이 많이 소모됩니다.

• 서버와 클라이언트가 모두 동일한 시스템에서 실행 중인 경우 TCP/IP 루프백과 Unix 도메인 소켓을 모두 사용할 수 있습니다. Linux의 경우 Unix 소켓을 사용하는 것이 TCP/IP 루프백보다 50% 더 빠를 수 있습니다. redis-benchmark는 기본적으로 TCP/IP 루프백 인터페이스를 사용합니다.

• 무거운 파이프라이닝을 사용하면 Unix 도메인 소켓의 이점이 덜 중요해집니다.

• 네트워크 연결을 사용하고 이더넷 패킷 크기가 1500바이트 미만인 경우 여러 명령을 파이프라이닝으로 패키징하면 효율성이 크게 향상될 수 있습니다. 실제로 10바이트, 100바이트, 1000바이트의 요청을 처리할 때 처리량은 거의 동일합니다. 자세한 내용은 아래 그림을 참조하세요.

• 멀티 코어 CPU 서버의 Redis 성능은 NUMA 구성 및 프로세서 바인딩 위치에 따라 달라집니다. Redis-benchmark의 가장 중요한 영향은 CPU 코어를 무작위로 활용한다는 것입니다. 정확한 결과를 얻으려면 고정 프로세서 도구를 사용해야 합니다(Linux에서는 taskset 또는 numactl을 사용할 수 있음). 가장 효과적인 방법은 클라이언트와 서버를 서로 다른 두 개의 CPU로 분리하여 3차 캐시를 사용하는 것입니다. 다음은 3개의 CPU(AMD Istanbul, Intel Nehalem EX 및 Intel Westmere)에 대해 서로 다른 구성을 사용하여 4KB 데이터 SET을 사용하는 일부 벤치마크입니다. 이는 CPU별 테스트가 아니라는 점에 유의하세요.

• 높은 구성에서는 클라이언트 연결 수도 중요한 요소입니다. Redis의 이벤트 루프는 epoll/kqueue의 이점을 활용하므로 확장성이 뛰어납니다. Redis는 60,000개 이상의 연결로 벤치마킹되었으며 여전히 50,000q/s를 유지할 수 있습니다. 경험상 30,000개의 연결은 100개의 연결 처리량의 절반에 불과합니다. 다음은 연결 수와 처리량에 대한 테스트입니다.

• 在高配置下面，可以通过调优 NIC 来获得更高性能。最高性能在绑定 Rx/Tx 队列和 CPU 内核下面才能达到，还需要开启 RPS（网卡中断负载均衡）。更多信息可以在thread。Jumbo frames 还可以在大对象使用时候获得更高性能。

• 在不同平台下面，Redis 可以被编译成不同的内存分配方式（libc malloc, jemalloc, tcmalloc），他们在不同速度、连续和非连续片段下会有不一样的表现。若非编译自行进行的 Redis，可用 INFO 命令验证内存分配方式。 请注意，大部分基准测试不会长时间运行来感知不同分配模式下面的差异， 只能通过生产环境下面的 Redis 实例来查看。

其他需要注意的点

任何基准测试的一个重要目标是获得可重现的结果，这样才能将此和其他测试进行对比。

• 一个好的实践是尽可能在隔离的硬件上面测试。需要检查基准测试是否受到其他服务器活动的影响，如果无法实现的话。

• 有些配置（桌面环境和笔记本，有些服务器也会）会使用可变的 CPU 分配策略。 这种策略可以在 OS 层面配置。有些 CPU 型号相对其他能更好的调整 CPU 负载。 为了达到可重现的测试结果，最好在做基准测试时候设定 CPU 到最高使用限制。

• 一个重要因素是配置尽可能大内存，千万不要使用 SWAP。注意 32 位和 64 位 Redis 有不同的内存限制。

• 注意在执行基准测试时，如果使用了 RDB 或 AOF，请避免同时进行其他 I/O 操作。 避免将 RDB 或 AOF 文件放到 NAS 或 NFS 共享或其他依赖网络的存储设备上面（比如 Amazon EC2 上 的 EBS）。

• 将 Redis 日志级别设置到 warning 或者 notice。避免将日志放到远程文件系统。

• 避免使用检测工具，它们会影响基准测试结果。查看服务器状态可使用 INFO 命令，但使用 MONITOR 命令会严重影响测试准确性。

不同云主机和物理机器上的基准测试结果

• 这些测试模拟了 50 客户端和 200w 请求。

• 使用了 Redis 2.6.14。

• 使用了 loopback 网卡。

• key 的范围是 100 w。

• 同时测试了 有 pipelining 和没有的情况（16 条命令使用 pipelining）。

Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (with pipelining)

$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q
SET: 552028.75 requests per second
GET: 707463.75 requests per second
LPUSH: 767459.75 requests per second
LPOP: 770119.38 requests per second

Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (without pipelining)

$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q
SET: 122556.53 requests per second
GET: 123601.76 requests per second
LPUSH: 136752.14 requests per second
LPOP: 132424.03 requests per second

Linode 2048 instance (with pipelining)

$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q -P 16
SET: 195503.42 requests per second
GET: 250187.64 requests per second
LPUSH: 230547.55 requests per second
LPOP: 250815.16 requests per second

Linode 2048 instance (without pipelining)

$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q
SET: 35001.75 requests per second
GET: 37481.26 requests per second
LPUSH: 36968.58 requests per second
LPOP: 35186.49 requests per second

更多使用 pipeline 的测试

$ redis-benchmark -n 100000

====== SET ======
  100007 requests completed in 0.88 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

58.50% <p>注意：包大小从 256 到 1024 或者 4096 bytes 不会改变结果的量级 （但是到 1024 bytes 后，GETs 操作会变慢）。同样的，50 到 256 客户端的测试结果相同。当使用10个客户端时，总吞吐量无法达到最大吞吐量。</p><p>不同机器可以获的不一样的结果，下面是Intel T5500 1.66 GHz 在 Linux 2.6下面的结果：</p><pre class="brush:php;toolbar:false">$ ./redis-benchmark -q -n 100000
SET: 53684.38 requests per second
GET: 45497.73 requests per second
INCR: 39370.47 requests per second
LPUSH: 34803.41 requests per second
LPOP: 37367.20 requests per second

另外一个是 64 位 Xeon L5420 2.5 GHz 的结果：

$ ./redis-benchmark -q -n 100000
PING: 111731.84 requests per second
SET: 108114.59 requests per second
GET: 98717.67 requests per second
INCR: 95241.91 requests per second
LPUSH: 104712.05 requests per second
LPOP: 93722.59 requests per second

高性能硬件下面的基准测试

• Redis2.4.2 。

• 默认连接数，数据包大小 256 bytes。

• Linux 是SLES10 SP3 2.6.16.60-0.54.5-smp，CPU 是 2 xIntel X5670 @ 2.93 GHz。

• 固定 CPU，但是使用不同 CPU 内核。

使用 unix domain socket：

$ numactl -C 6 ./redis-benchmark -q -n 100000 -s /tmp/redis.sock -d 256
PING (inline): 200803.22 requests per second
PING: 200803.22 requests per second
MSET (10 keys): 78064.01 requests per second
SET: 198412.69 requests per second
GET: 198019.80 requests per second
INCR: 200400.80 requests per second
LPUSH: 200000.00 requests per second
LPOP: 198019.80 requests per second
SADD: 203665.98 requests per second
SPOP: 200803.22 requests per second
LPUSH (again, in order to bench LRANGE): 200000.00 requests per second
LRANGE (first 100 elements): 42123.00 requests per second
LRANGE (first 300 elements): 15015.02 requests per second
LRANGE (first 450 elements): 10159.50 requests per second
LRANGE (first 600 elements): 7548.31 requests per second

使用 TCP loopback：

$ numactl -C 6 ./redis-benchmark -q -n 100000 -d 256
PING (inline): 145137.88 requests per second
PING: 144717.80 requests per second
MSET (10 keys): 65487.89 requests per second
SET: 142653.36 requests per second
GET: 142450.14 requests per second
INCR: 143061.52 requests per second
LPUSH: 144092.22 requests per second
LPOP: 142247.52 requests per second
SADD: 144717.80 requests per second
SPOP: 143678.17 requests per second
LPUSH (again, in order to bench LRANGE): 143061.52 requests per second
LRANGE (first 100 elements): 29577.05 requests per second
LRANGE (first 300 elements): 10431.88 requests per second
LRANGE (first 450 elements): 7010.66 requests per second
LRANGE (first 600 elements): 5296.61 requests per second

위 내용은 Redis 벤치마크 매개변수를 확인하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!