이전 기사에서 Redis 인스턴스가 느려지는 것을 방지하기 위한 주제와 접근 방식에 대해 논의했습니다. 이제 측정 방법을 검토할 때입니다. 성능.
측정 대상
이 기사에서는 명령 지연 시간과 해당 구성 요소를 살펴보겠습니다. 왜요? Redis 서버/라이브러리를 통해 푸시할 수 있는 명령의 수는 각 명령의 속도에 따른 결과이기 때문입니다.
빠르고 쉬운:CLI
명령 대기 시간을 확인하는 첫 번째 방법은 명령줄 클라이언트 redis-cli를 사용하는 것입니다. . 빠르고 시작할 수 있는 즉각적인 체크포인트를 제공합니다. 여기의 예는 단순성을 위해 localhost를 사용하지만 설정에서는 -h <host>를 사용해야 합니다. 옵션 및 필요한 경우 -a <auth> 및 -p <port> .
기본 지연 시간
기본 대기 시간 결과를 얻으려면 redis-cli –latency를 실행합니다. 이것은 최소, 최대, 평균 및 반복 횟수를 나타내는 숫자 세트를 출력합니다. 이러한 반복은 열린 연결에 대해 Redis 명령 PING을 실행하는 것으로 구성됩니다. 따라서 서버에 연결할 시간은 포함되지 않습니다. 코드가 모든 명령에 연결되면 이 명령이 나타내는 것보다 훨씬 더 나쁜 성능을 볼 수 있습니다.
이 명령은 죽일 때까지 실행됩니다. CTRL-C를 통해 쉽게 수행할 수 있습니다. 대기 시간 수는 밀리초 단위입니다. 따라서 다음의 결과:
min: 0, max: 1, avg: 0.11 (11369 samples)최소 대기 시간이 1밀리초 미만이고 최대가 1밀리초이며 평균 PING당 대기 시간이 0.11밀리초임을 의미합니다. 예, 이것은 localhost 연결입니다. 이 숫자는 11,369개의 "샘플" 또는 PING 명령에서 계산된 결과입니다.
또는 대신 –latency-history를 사용할 수 있습니다. 이 옵션을 사용하면 시간 조각으로 나눌 수 있습니다. redis-cli –latency-history를 실행하면 15초의 기본 창을 사용합니다. 결과는 다음과 같습니다.
min: 0, max: 1, avg: 0.11 (1475 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.10 (1474 samples) -- 15.01 seconds range–latency와 마찬가지로 이 명령은 종료할 때까지 실행됩니다. 다른 간격으로 실행하려면 -i 를 전달할 수 있습니다. 예:
redis-cli --latency-history -i 10
min: 0, max: 1, avg: 0.11 (984 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.11 (983 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.11 (983 samples) -- 10.01 seconds range이러한 작업은 단순히 PING 명령을 사용하기 때문에 모든 Redis 버전에서 작동해야 합니다.
내재적 지연 시간
언뜻 보기에 이름을 보면 내부 대기 시간 모드가 서버의 고유 대기 시간을 측정한다고 생각할 수 있습니다. 그렇지 않다. GitHub의 redis-cli 소스를 보면 서버와 통신조차 하지 않는다는 것을 알 수 있습니다.
start = ustime();
compute_something_fast();
end = ustime();
latency = end-start;고유 대기 시간 모드에 대한 소스 의견에 따르면:
<블록 인용>시스템 호출로 인해 발생하지 않는 실행 중인 프로세스의 최대 대기 시간을 측정합니다. 기본적으로 이 소프트웨어는 커널이 실행할 기회 없이 프로세스를 떠나는 시간에 대한 힌트를 제공해야 합니다.
이것이 하는 일은 클라이언트 호스트에서 고유 대기 시간을 테스트하는 것입니다. . 이것은 문제가 실제로 서버 자체가 아니라 클라이언트 측에 있는지 여부를 아는 데 유용합니다.
따라서 유용하기는 하지만 대기 시간을 확인하는 첫 번째 단계에 있어서는 안 됩니다. 업데이트 :Salvatore와 대화한 후 그는 서버에서 이 명령을 실행하려는 의도를 확인했습니다. 즉, Redis 서버에 대한 셸 액세스 권한이 있는 경우 유용할 수 있지만 그렇지 않은 경우에는 유용하지 않습니다. 일반적으로 Redis 서비스 제공업체를 사용하는 경우입니다.
위원 사용
Commissar는 Redis 대기 시간 및 전체 성능을 추적하고 테스트하기 위해 작업 중인 작은 제품군입니다. 경고:개발 초기 단계이며 많은 것이 변경될 것입니다. 이러한 이유로 프로덕션 품질이 아닌 소프트웨어를 사용하는 것이 편안하다고 느끼는 경우에만 사용하십시오. Commissar님은 The Github Commissar Repository에 있습니다.
특히 이 기사에서는 대기 시간 도구/디렉토리를 살펴볼 것입니다.
환경 변수를 통해 구성된 이 도구는 지정된 Redis 인스턴스에 연결하고 redis-cli와 동일한 "PING 명령 시간" 메커니즘을 실행합니다. 테스트의 패리티를 유지하기 위해 이 작업을 수행했습니다. 다른 점은 더 많은 정보를 출력하고 (현재) MongoDB에 저장하는 기능입니다. 앞으로 더 많은 상점이 생길 것입니다.
이 문서가 작성된 이후로 출력이 변경되었을 가능성이 있지만 지연 실행은 다음과 같을 수 있습니다.
./latency
Connected to <host:ip>
100000 iterations over 53698us, average 536us/operation
Percentile breakout:
====================
99.00%: 3,876.99us
95.00%: 640.00us
90.00%: 514.00us
75.00%: 452.00us
50.00%: 414.00us
Min: 243us
Max: 44,686us
Mean: 536.98us
Jitter: 764.37us이 실행에서 시간 단위는 'us'(즉, 마이크로초)입니다. 또한 백분위수 브레이크아웃을 제공하는 것을 볼 수 있습니다. 이를 통해 간단한 min/max/avg와 비교하여 지연 시간이 어떻게 보이는지 더 잘 이해할 수 있습니다. 이 맥락에서 'Jitter'는 샘플의 표준 편차입니다.
이 출력은 우리가 전반적으로 꽤 좋아 보인다는 것을 알려줍니다. 이 특정 예는 개인 네트워크를 통한 것입니다. 피크가 평균보다 훨씬 높지만 95%의 반복이 640마이크로초 이하에서 발생한다는 것을 알 수 있습니다. 이것은 우리에게 무엇을 알려줍니까?
산발적인 네트워크 문제, 산발적인 서버 측 지연 또는 출력에 영향을 미치는 테스트 클라이언트의 가비지 제어와 같은 문제가 있음을 알려줄 수 있습니다. 이것이 요청 분포가 가능한 이유입니다. 따라서 "높은" 결과가 얼마나 흔한지 알 수 있습니다.
문제가 있는 위치를 확인하려면 먼저 서버의 명령이 얼마나 오래 걸리는지 확인해야 합니다. 서버에 문제가 있는지 알려줍니다.
이 경우 예를 들어, 특히 Commandstats 섹션을 살펴보고 redis 정보 출력을 확인하고 싶을 수 있습니다.
redis-cli info commandstats
# Commandstats
cmdstat_ping:calls=32497193,usec=22213723,usec_per_call=0.68여기서 우리는 서버에서 PING을 실행하는 평균 시간이 0.68마이크로초임을 알 수 있습니다. 분명히 ping 명령 자체가 범인일 가능성은 없습니다. 그러나 테스트 중에 Redis 프로세스를 지원하는 다른 명령이 실행되어 지연이 발생할 수 있습니다.
최근 대기 시간 도구에 추가된 기능은 동시 대기 시간 테스트를 실행하는 기능입니다. LATENCY_CLIENTCOUNT에 환경 변수를 설정하여 Redis 서버에 대한 다중 연결을 실행하고 동시성이 대기 시간 결과에 얼마나 영향을 미치는지 확인할 수 있습니다. 예를 들어 10개의 클라이언트와 100개 또는 1000개의 동시 클라이언트가 있는 경우 간단한 Redis PING 명령이 표시하는 차이점을 볼 수 있습니다. 이것은 개발/스테이징과 프로덕션 간에 경험할 수 있는 차이점을 확인하는 데 유용할 수 있습니다.
컨테이너에서 테스트
Docker 컨테이너에서 테스트를 실행하시겠습니까? 이제 golatency 도구만 포함된 빌드된 Docker 컨테이너를 공개 Docker 레지스트리에 푸시합니다. docker pull realbill/golatency를 수행하면 몇 초 만에 실행할 준비가 된 이미지를 얻을 수 있습니다(현재 이미지 크기는 4MB 미만임).
ReadMe가 나타내는 대로 연결하고 구성하려면 환경 변수와 함께 docker run을 호출하기만 하면 됩니다. 그런 다음 stdout에서 출력을 가져오거나 도커 로그를 통해 데몬으로 실행하면 아무 것도 빌드할 필요가 없습니다. 도구를 크게 변경할 때마다 Docker 저장소가 새 이미지로 업데이트됩니다. 또는 저장소에 Dockerfile이 있어 원하는 대로 사용자 지정할 수 있습니다.
최종 생각
Redis로 성능을 분석하는 것은 까다로울 수 있습니다. 다행히 대기 시간과 처리량과 이것이 애플리케이션에 미치는 영향을 이해하면 Redis 자체보다 애플리케이션의 Redis 사용 분석에 더 집중할 수 있습니다. Zen of Redis의 "성능의 핵심은 Redis의 속도를 늦추지 않는 것"이라는 문구를 유념하여 Redis를 사용하는 가장 좋은 방법에 대한 이해도를 높이고 네트워크 문제와 데이터 구조 대안을 분리하여 더 스마트하고 효율적인 애플리케이션을 생성합니다. , 결과적으로 더 나은 성능을 제공합니다.