1. 요청 응답 프로토콜 및 RTT:
Redis는 C/S 모델을 기반으로 하는 일반적인 TCP 서버입니다. 클라이언트와 서버 사이의 통신 과정에서 일반적으로 클라이언트는 요청을 먼저 시작하고, 서버는 요청을 받은 후 해당 작업을 수행하고, 마지막으로 획득한 데이터나 처리 결과를 응답 형식으로 클라이언트에 보냅니다. 이 프로세스 동안 클라이언트는 서버가 반환하는 결과를 차단하는 방식으로 기다립니다. 다음 명령 순서를 참조하세요.
Client: INCR X Server: 1 Client: INCR X Server: 2 Client: INCR X Server: 3 Client: INCR X Server: 4
요청과 응답의 각 쌍 과정에서 네트워크 전송으로 인한 추가 오버헤드를 부담해야 합니다. 우리는 일반적으로 이 오버헤드를 RTT(Round Trip Time)라고 부릅니다. 이제 각 요청과 응답의 RTT가 250밀리초이고 서버가 1초에 100,000개의 데이터를 처리할 수 있다고 가정하지만 결과적으로 서버는 초당 최대 4개의 요청을 처리할 수 있습니다. 이 성능 문제를 해결하려면 어떻게 최적화할 수 있습니까?
2. 파이프라이닝:
Redis는 초기 버전에서 명령 파이프라인에 대한 지원을 제공했습니다. 구체적인 설명을 하기 전에 먼저 위의 동기 응답 방식의 예를 명령 파이프라인을 기반으로 한 비동기 응답 방식으로 변환하여 모든 사람이 더 나은 지각적 이해를 가질 수 있도록 하겠습니다.
Client: INCR X Client: INCR X Client: INCR X Client: INCR X Server: 1 Server: 2 Server: 3 Server: 4
위의 예에서 볼 수 있듯이 클라이언트는 명령을 보낸 후 즉시 서버의 응답을 기다릴 필요가 없고 계속해서 후속 명령을 보낼 수 있습니다. 명령이 전송된 후 이전 명령에 대한 응답을 한 번에 읽습니다. 이렇게 하면 동기 모드에서 RTT 오버헤드가 절약됩니다.
마지막으로 주의할 점은 Redis 서버가 클라이언트의 요청이 파이프라인 기반이라는 것을 알게 되면, 서버는 요청을 받아 처리한 후 각 명령의 응답 데이터를 대기열에 저장한 후 전송한다는 것입니다. 클라이언트에게.
3. 벤치마크:
다음은 Redis 공식 홈페이지의 테스트 사례 및 테스트 결과입니다. 이 테스트는 루프백(127.0.0.1)을 기반으로 하므로 RTT에 소요되는 시간은 상대적으로 적습니다. 실제 네트워크 인터페이스를 기반으로 한다면 파이프라인 메커니즘으로 인한 성능 향상은 더욱 커집니다. 중요한.
require 'rubygems' require 'redis' def bench(descr) start = Time.now yield puts "#{descr} #{Time.now-start} seconds" end def without_pipelining r = Redis.new 10000.times { r.ping } end def with_pipelining r = Redis.new r.pipelined { 10000.times { r.ping } } end bench("without pipelining") { without_pipelining } bench("with pipelining") { with_pipelining } //without pipelining 1.185238 seconds //with pipelining 0.250783 seconds
위는 Redis Tutorial(13) 내용입니다. 파이프라인에 대한 자세한 설명은 PHP 중국어 홈페이지(m.sbmmt.com)를 참고해주세요!