Redis 벤치마크

Redis 벤치마크 (Redis benchmark)

Redis는 redis-benchmark 유틸리티를 제공해 N개 클라이언트가 동시에 총 M개 쿼리를 보내는 상황을 시뮬레이션합니다(Apache의 ab와 유사). 사전에 실행 중인 Redis 인스턴스가 필요하며, 대표 예시는 다음과 같습니다.

redis-benchmark -q -n 100000

출처: 공식문서

주요 옵션

redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests>] [-k <boolean>]
  • -h <hostname> / -p <port>: 서버 주소(기본 127.0.0.1 / 6379)
  • -s <socket>: 서버 소켓(host/port 대체)
  • -a <password>: Redis Auth 비밀번호, --user로 ACL 방식 AUTH username pass 전송
  • -c <clients>: 병렬 연결 수(기본 50)
  • -n <requests>: 총 요청 수(기본 100000)
  • -d <size>: SET/GET 값 크기 바이트(기본 3)
  • --dbnum <db>: 선택할 DB 번호(기본 0)
  • --threads <num>: 멀티스레드 모드, --cluster: 클러스터 모드
  • --enable-tracking: 벤치마크 전에 CLIENT TRACKING 전송
  • -k <boolean>: 1=keep alive 0=reconnect(기본 1)
  • -r <keyspacelen>: 무작위 키 사용. rand_int를 0~keyspacelen-1 범위의 12자리 숫자로 치환
  • -P <numreq>: 파이프라인 요청 수(기본 1=파이프라인 없음)
  • -e: 오류를 stdout으로 표시, -q: 조용히 q/s만 표시
  • --precision: 지연 출력 소수점 자릿수, --csv: CSV 출력
  • -l: 반복 실행, -t <tests>: 쉼표로 구분한 테스트만 실행
  • -I: 유휴 모드(N개 연결만 열고 대기), --help/--version

부분 테스트 실행 (-t)

$ redis-benchmark -t set,lpush -n 100000 -q
SET: 180180.17 requests per second, p50=0.143 msec
LPUSH: 188323.91 requests per second, p50=0.135 msec

명령을 직접 지정할 수도 있습니다.

$ redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"

키 공간 크기 (-r)와 파이프라인 (-P)

-r로 큰 키 공간을 쓰면 캐시 미스와 실제 워크로드에 가까운 부하를 시뮬레이션합니다. -P 16처럼 파이프라인을 쓰면 처리량이 크게 올라갑니다.

$ redis-benchmark -n 1000000 -t set,get -P 16 -q
SET: 1536098.25 requests per second, p50=0.479 msec
GET: 1811594.25 requests per second, p50=0.391 msec

함정과 오해

  • 사과끼리 비교: 다른 버전의 Redis끼리, 또는 같은 버전의 다른 옵션끼리 비교해야 합니다. 타 제품과 비교할 땐 기능·기술 차이를 반드시 반영하세요.
  • Redis는 서버라 모든 명령이 네트워크 왕복을 수반합니다. 임베디드 데이터스토어와 비교할 땐 왕복 시간이 아닌 명령 실행 시간으로 보세요.
  • 동기 명령을 단순 반복하면 Redis가 아니라 네트워크/클라이언트 라이브러리 지연을 잰 셈입니다. 여러 연결과 파이프라인·멀티스레드를 써야 합니다.
  • Redis는 대부분 단일 스레드 명령 실행이므로 멀티코어 확장형 DB와의 단일 인스턴스 비교는 공정하지 않습니다. 여러 인스턴스를 띄워 스케일 아웃합니다.
  • 기본 redis-benchmark는 파이프라인 없이 오직 동시성만으로 처리량을 냅니다. -P를 명시해야 최대 처리량에 근접하며, 실제 애플리케이션의 평균 파이프라인 길이에 맞춰 현실적인 수치를 얻는 것이 좋습니다.

Redis 성능에 영향을 주는 요소

  • 네트워크 대역폭·지연: Redis는 종종 CPU보다 네트워크가 먼저 병목이 됩니다. 4KB 문자열을 100000 q/s로 넣으면 약 3.2 Gbit/s를 소비하므로 10 Gbit/s 링크는 되지만 1 Gbit/s는 부족합니다.
  • CPU: 단일 스레드 특성상 코어 수보다 큰 캐시·고클럭 CPU가 유리합니다.
  • RAM 속도: 소형 객체엔 크게 중요하지 않지만 10KB 이상 대형 객체에선 체감될 수 있습니다.
  • 가상화/VM: 동일 하드웨어에서 물리 머신보다 느립니다. 다른 조건이 같다면 물리 머신 권장.
  • Unix 도메인 소켓: 플랫폼에 따라 TCP 루프백보다 약 50% 더 높은 처리량을 내며, 긴 파이프라인 사용 시 그 이점은 줄어듭니다.
  • NUMA/코어 배치: 멀티 소켓 서버에선 taskset/numactl로 클라이언트·서버를 같은 CPU의 다른 코어에 배치해 L3 캐시를 활용하면 결정적인 결과를 얻습니다.
  • 연결 수: epoll/kqueue 기반 이벤트 루프는 확장성이 좋아 60000개 이상 연결도 감당하며, 대략 30000 연결이면 100 연결의 절반 처리량입니다.
  • 메모리 할당자: libc malloc, jemalloc, tcmalloc 간 속도·파편화가 다르며, INFO의 mem_allocator로 확인 가능합니다.

재현 가능한 벤치마크

격리된 하드웨어에서 실행하고, CPU 주파수 스케일링을 꺼 고정 주파수로 맞추며, 램 부족·스왑이 없게 하고, overcommit_memory를 올바르게 설정하세요. RDB/AOF를 쓴다면 NAS/NFS/EBS처럼 네트워크 대역폭과 지연에 영향을 주는 장치를 피하세요. 로깅 레벨은 warning/notice로 하고, MONITOR는 측정 성능에 큰 영향을 주므로 회피합니다.

기타 벤치마크 도구

  • memtier_benchmark(Redis Labs): NoSQL Redis/Memcache 트래픽 생성 및 벤치마크.
  • rpc-perf(Twitter): RPC 서비스 벤치마크로 Redis/Memcache 지원.
  • YCSB(Yahoo): 여러 DB 클라이언트를 지원하는 벤치마크 프레임워크.

더 알아보기 (Learn more)