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 命令会严重影响测试准确性。
不同云主机和物理机器上的基准测试结果
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
로그인 후 복사
高性能硬件下面的基准测试
使用 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 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
