Stackexchange.Redis를 사용하여 MGET 호출 속도가 느려지고 느려짐

Question

AWS ECS의 Linux 컨테이너에서 실행되는 ASP.Net 핵심 웹 API가 있습니다. 이 API는 대부분 Redis에서 데이터를 가져 오지만 데이터가 없으면 데이터베이스로 폴백합니다 (데이터의 99.99 %가 Redis 캐시에있는 경우 엔지니어링했습니다). 나는 합리적으로 높은 부하가 약 1-2K RPS (아마도 당신 중 일부에 중소 ~;)에 들어오고있다.

이 API는 각 요청에 대해 MGET (20-60의 모든 위치)를 통해 여러 키를 조회합니다. 모든 것이 비동기이며, 동기 코드 또는 대기 또는 다른 교착 상태가 자주 발생하는 코드는 없습니다. RPS가 갈수록 속도가 느려지고 느려집니다. 또한 PreserveAsyncOrder = false를 시도했지만 더 나 빠졌다.

Elasticache에있는 Redis 서버가 문제가 아니라고 생각합니다. 통계는 거의 1 %의 CPU 사용률을 보여줍니다. 또한 생성하는 컨테이너의 인스턴스가 많을수록 대기 시간이 길어지고 서버가 병목 현상이 발생할 경우 기대하지 않을 일이 생깁니다.

TPL 및 SE.Redis (고정 또는 비 호환인지, 또는 .Net Core에 해당하는지 확실하지 않음)와 관련하여 잠재적 인 스레드 도용 문제가 있다고 들었으므로 모든 것을 비동기가 아닌 동기화로 이동하려고 시도했습니다. 웹 API 호출은 여전히 ​​비동기이지만 SE.Redis에 대한 호출은 동기화 됨).

MGET, inst : 5, queue : 199, qu : 0, qs : 199, qc : 0, wr : 0, wq : 0, in : 150304의 시간 초과를 수행하는 타임 아웃이 발생했습니다. , ar : 0, clientName :, serverEndpoint : 10.55.148.227:6379, keyHashSlot : -2

이것은 .Net Core이므로 타임 아웃 예외는 전체 스택보다 적은 정보를 제공하는 것 같습니다. 작업자 스레드 또는 IOCP 스레드에 병목 현상이 있는지 확인하십시오.

대기 시간이 길어짐에 따라 대기열/qs : 번호는 in : 번호와 함께 올라갑니다.

숫자가 너무 빨라 응답을 얻지 못하고 있다는 것을 알게되고, 스레드 하이재킹 문제에 빠질 수 있습니까? 아니면 내 클라이언트가 네트워크 바운드인가?

또한 SE.Redis 시간 초과 페이지에 표시된 것처럼 redis 연결을위한 연결 풀을 만들려고했습니다. 아주 작은 개선이지만 여전히 같은 문제에 직면 해 있습니다.

도움을 주시면 감사하겠습니다.

Answer 1

Redis는 단일 스레드입니다. 단일 스레드에서로드가 증가하므로 응답 속도가 느려집니다. MGET은 단일 일괄 처리에서 여러 번의 GET 작업이므로 각 요청에 대해 20-60 GET을 수행하고 초당 2k 요청을 수행하는 경우 Redis는 약 30-120k ops/초를 수행합니다.

클라우드 VMCP 또는 네트워크 채도에 대한 최대 처리량이 어느 쪽이든과 다릅니다.

무작위 키를 사용하여 일부로드 테스트를 수행하여 최대 용량을 먼저 확인하여 응용 프로그램에 충분한 지 알아 낸 다음 해당 용량을 모델링 할 수 있습니다.

해시를 사용하여 유사한 데이터를 단일 키로 결합하거나 더 많은 서버 (또는 더 많은 CPU의 인스턴스)와 샤딩을 사용할 수 있습니다. Redis 클러스터는 자동 샤딩을 수행합니다.