Redis Benchmark

 

Redis Benchmark는 Redis 서버의 성능을 측정하기 위한 내장 테스트 도구입니다. Redis를 설치하면 함께 제공되며, 다양한 명령어에 대해 초당 처리량, 지연 시간 등을 측정할 수 있습니다.

🚀 Redis Benchmark란?

• redis-benchmark는 Redis 서버에 대해 N개의 클라이언트가 M개의 요청을 동시에 보내는 시뮬레이션을 수행합니다.
• Apache의 ab 벤치마크 도구와 유사한 방식으로 작동합니다.
• Redis의 처리 속도, 응답 시간, 병렬 처리 성능 등을 테스트할 수 있습니다.

 

⚙️ 기본 사용법

bash

redis-benchmark -h <host> -p <port> -c <clients> -n <requests>

 

옵션설명

 

-h	Redis 서버 호스트 (기본: 127.0.0.1)
-p	포트 번호 (기본: 6379)
-c	병렬 클라이언트 수 (기본: 50)
-n	총 요청 수 (기본: 100000)
-d	SET/GET 값의 크기 (기본: 3바이트)
-t	테스트할 명령어 지정 (예: set,get)
-P	파이프라인 요청 수
--cluster	클러스터 모드 활성화
--csv	결과를 CSV 형식으로 출력
-q	간단한 결과만 출력 (quiet mode)

 

🧪 예시

bash

redis-benchmark -t set,get -n 100000 -q

 

출력 예시:

SET: 1536098.25 requests per second, p50=0.479 msec
GET: 1811594.25 requests per second, p50=0.391 msec

• p50은 50% 지연 시간 분포 (중앙값)
• 초당 처리량이 150만~180만건 이상으로 매우 빠름

 

📊 주요 테스트 항목

 

명령어	설명
PING_INLINE, PING_BULK	연결 테스트
SET, GET, INCR	기본 키-값 연산
LPUSH, RPUSH, LPOP, RPOP	리스트 연산
SADD, SPOP	집합 연산
HSET	해시 연산
LRANGE	리스트 조회
MSET	다중 키 설정

 

🧩 <팁> 주의사항

• 파이프라인(-P)을 사용하면 성능이 크게 향상됩니다.
• 단일 키 테스트는 실제 환경과 다를 수 있으므로 -r 옵션으로 랜덤 키를 사용하는 것이 좋습니다.
• Redis는 단일 스레드 기반이므로 CPU 코어를 활용하려면 여러 인스턴스를 띄우는 방식이 필요합니다.
• flushall 명령으로 테스트 전 데이터를 초기화할 수 있습니다.

 

다음은 PC에 설치한 Redis 의 성능테스트 결과 입니다.

🧪 redis-benchmark  Result

[root@vbox yum.repos.d]# redis-benchmark
Summary:
  throughput summary: 153609.83 requests per second
  latency summary (msec):
          avg       min       p50       p95       p99       max
        0.219     0.056     0.183     0.423     0.711     1.735
====== XADD ======
  100000 requests completed in 0.67 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 3600 1 300 100 60 10000
  host configuration "appendonly": no
  multi-thread: no

Latency by percentile distribution:
0.000% <= 0.063 milliseconds (cumulative count 2)
50.000% <= 0.175 milliseconds (cumulative count 51998)
75.000% <= 0.239 milliseconds (cumulative count 76430)
87.500% <= 0.311 milliseconds (cumulative count 88044)
93.750% <= 0.383 milliseconds (cumulative count 94079)
96.875% <= 0.455 milliseconds (cumulative count 97072)
98.438% <= 0.551 milliseconds (cumulative count 98460)
99.219% <= 0.711 milliseconds (cumulative count 99225)
99.609% <= 0.911 milliseconds (cumulative count 99614)
99.805% <= 1.087 milliseconds (cumulative count 99805)
99.902% <= 1.263 milliseconds (cumulative count 99904)
99.951% <= 1.375 milliseconds (cumulative count 99952)
99.976% <= 2.143 milliseconds (cumulative count 99976)
99.988% <= 2.263 milliseconds (cumulative count 99989)
99.994% <= 2.279 milliseconds (cumulative count 99995)
99.997% <= 2.295 milliseconds (cumulative count 99997)
99.998% <= 2.439 milliseconds (cumulative count 99999)
99.999% <= 2.447 milliseconds (cumulative count 100000)
100.000% <= 2.447 milliseconds (cumulative count 100000)

Cumulative distribution of latencies:
1.641% <= 0.103 milliseconds (cumulative count 1641)
67.734% <= 0.207 milliseconds (cumulative count 67734)
87.073% <= 0.303 milliseconds (cumulative count 87073)
95.401% <= 0.407 milliseconds (cumulative count 95401)
97.916% <= 0.503 milliseconds (cumulative count 97916)
98.792% <= 0.607 milliseconds (cumulative count 98792)
99.202% <= 0.703 milliseconds (cumulative count 99202)
99.444% <= 0.807 milliseconds (cumulative count 99444)
99.602% <= 0.903 milliseconds (cumulative count 99602)
99.730% <= 1.007 milliseconds (cumulative count 99730)
99.821% <= 1.103 milliseconds (cumulative count 99821)
99.879% <= 1.207 milliseconds (cumulative count 99879)
99.919% <= 1.303 milliseconds (cumulative count 99919)
99.957% <= 1.407 milliseconds (cumulative count 99957)
99.963% <= 1.503 milliseconds (cumulative count 99963)
99.971% <= 2.103 milliseconds (cumulative count 99971)
100.000% <= 3.103 milliseconds (cumulative count 100000)

Summary:
  throughput summary: 148588.42 requests per second
  latency summary (msec):
          avg       min       p50       p95       p99       max
        0.208     0.056     0.175     0.399     0.655     2.447

 

🚀 처리량(Throughput) 요약

• 총 처리량: 153,609 requests/sec

📌 XADD은 Redis Streams에서 데이터를 추가할 때 사용하는 명령이며, 상대적으로 복잡한 연산에 속합니다.

→ 이 수치는 단일 스레드 기반 Redis 서버에서도 꽤 높은 성능입니다. 일반적인 웹 애플리케이션이나 실시간 로그 수집 시스템에서 충분히 사용할 수 있어요.

 

⏱️ 지연 시간(Latency) 요약

지표값 (ms)해석

평균	0.219	전반적으로 매우 빠름
최소	0.056	네트워크/서버 상태 양호
p50	0.183	요청의 절반이 0.183ms 이내 처리됨
p95	0.423	95%가 0.423ms 이내 처리됨 — 안정적
p99	0.711	1%가 이보다 오래 걸림
최대	1.735	최악의 경우도 2ms 미만 — 대기 시간 폭발 없음

🎯 지연 시간이 전반적으로 짧고 일관성 있음. 특히 p95 이하의 응답이 0.5ms 미만인 점은 고성능 애플리케이션에서도 매우 중요한 특성입니다.

 

🧮 Percentile 분포 요약

• 75% 이상 요청이 0.24ms 이내에 처리됨
• 99.9% 이상이 1.2ms 이내, 최대 2.4ms

✅ 즉, 거의 모든 요청이 매우 짧은 시간 내에 안정적으로 처리된다는 뜻입니다. 스트림 처리나 실시간 이벤트 큐 등에 적합한 성능이에요.

 

⚙️ 테스트 환경 요약

 

테스트 항목	결과 값
클라이언트 수	50 병렬
요청 수	100,000
Payload 크기	3 bytes
multi-thread	아니오
appendonly 설정	no (속도 위주 설정)

💡 appendonly가 비활성화되어 있어 디스크 기록 오버헤드가 없는 상태입니다. 실제 운영 환경에서는 appendonly yes로 변경 시 처리량이 약간 낮아질 수 있지만 안정성과 영속성은 높아집니다.

📌 총평

✅ 매우 빠르고 안정적인 처리 성능 ✅ Redis Streams 기반 XADD 테스트에서도 거의 모든 요청이 1ms 이하 🚦 운영 환경에서는 디스크 영속성(appendonly) 설정 및 멀티 쓰레드 여부에 따라 성능이 다를 수 있음