데이터 센터 내 지연 시간은 얼마입니까? 나는 차수의 차이가 있다고 가정하여 이것을 묻습니다

나는 좋은 대답을 찾을 수없는 것을 알아 내려고 노력하고 있습니다.

데이터 센터에 앉아있는 REDIS 캐시 (또는 일부 외부 메모리 내 캐시)와 동일한 데이터 센터에 앉아있는 응용 프로그램 서버에 대해 말하면 데이터 읽기를위한 네트워크 연결 속도 (지연 시간, 처리량)는 얼마입니까? 이 두 기계 사이?

예를 들어 네트워크 "속도"가 여전히 REDIS의 캐시에서 데이터를 찾는 RAM 속도보다 적어도 10 배나 더 높습니까?

내 궁극적 인 질문은-이 모든 것이 실제로 유틸리티를 제공하는 REDIS의 메모리에 앉아 있습니까? REDIS가이 모든 것을 대신 SSD에 캐싱하는 것과는 대조적인가? 메모리가 비싸다. 네트워크가 실제로 데이터 센터 내에서 병목 현상이 발생하지 않으면 메모리에 가치가 있습니다. 그렇지 않으면 그렇지 않습니다.

내 일반적인 질문은 데이터 센터의 광대 한 미지와 일반화 및 분산에 대한 불확실성에도 불구하고 컴퓨터 시스템의 메모리 대기 시간과 DC 내부의 최상의 네트워크 사이에서 메모리의 지연 시간 감소로 성능이 크게 향상되지 않습니까? 변수가 많지만 얼마나 가깝습니까? 이러한 변수가 중요 할 정도로 근접합니까? 예를 들어, 하이퍼 볼릭 자세를 취하고 테이프 드라이브는 네트워크보다 속도가 느리므로 테이프는 캐시에 적합하지 않습니다.

"모든 사람이 알아야하는 대기 시간 차트"에는 다음과 같은 여러 버전이 있습니다.

• https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html
• https://gist.github.com/jboner/2841832
• https://computers-are-fast.github.io/

실제로는 대기 시간 이상이 있습니다. 요인의 조합입니다.

그렇다면 데이터 센터 내에서 네트워크 대기 시간은 얼마입니까? 지연 시간은 1ms 미만의 "항상"이라고합니다. RAM보다 빠릅니까? 아니요. RAM에 가깝습니까? 나는 그렇게 생각하지 않습니다.

그러나 문제는 여전히 관련이 있습니다. 그게 당신이 알아야 할 자료입니까? 당신의 질문은 저에게 의미가 있습니다. 모든 것이 비용이 들기 때문에 더 많은 RAM을 확보해야 모든 데이터가 RAM에 남아 있거나 디스크를 수시로 읽을 수 있습니다.

"가정"은 네트워크 대기 시간이 SSD 속도보다 빠르거나 느리면 네트워크 속도가 느려 RAM의 모든 데이터를 가져와 얻는 것이 아니라는 것입니다.

그리고 그렇게 보일 것입니다. 그러나 동시성도 고려해야합니다. 한 번에 1,000 개의 데이터 요청을 수신하면 디스크가 1,000 개의 동시 요청을 수행 할 수 있습니까? 물론 1,000 건의 요청을 처리하는 데 얼마나 걸립니까? RAM에 비해?

무거운 하중과 같은 단일 요인으로 그것을 요약하기는 어렵습니다. 그러나 그렇습니다. 단일 작업을 진행하는 경우 네트워크 대기 시간은 SSD와 RAM의 차이를 인식하지 못할 정도입니다.

12Gbps 디스크가 시장에 나올 때까지 디스크에 병목 현상이 발생하여 10Gbps 네트워크 링크가 단일 스트림으로 과부하되지 않습니다.

그러나 디스크가 다른 많은 일을하고 있다는 것을 기억하십시오. 프로세스는 시스템의 유일한 프로세스는 아니며 네트워크는 다른 것을 수행 할 수 있습니다.

또한 모든 디스크 활동이 네트워크 트래픽을 의미하는 것은 아닙니다. 응용 프로그램에서 데이터베이스 서버로 들어오는 데이터베이스 쿼리는 네트워크 트래픽이 매우 적습니다. 데이터베이스 서버의 응답은 매우 작거나 (단일 숫자) 매우 클 수 있습니다 (여러 필드가있는 수천 행). 작업을 수행하기 위해 서버 (데이터베이스 서버 여부에 관계없이)는 여러 디스크 탐색, 읽기 및 쓰기를 수행해야하지만 네트워크를 통해 아주 작은 비트 만 다시 보내야합니다. 확실히 일대일 네트워크 디스크 RAM이 아닙니다.

지금까지 귀하의 질문에 대한 세부 사항, 특히 Redis 부분을 피했습니다.

Redis는 데이터베이스, 캐시 및 메시지 브로커로 사용되는 오픈 소스 (BSD 라이센스) 메모리 내 데이터 구조 저장소입니다. -https : //redis.io/

자, 그것은 모든 것이 메모리에 있다는 것을 의미합니다. 죄송합니다.이 빠른 SSD 드라이브는 여기서 도움이되지 않습니다. Redis는 데이터를 디스크에 유지할 수 있으므로 재시작 후 RAM에로드 할 수 있습니다. 이는 데이터를 "손실"하지 않거나 재시작 후 콜드 캐시를 다시 채워야합니다. 따라서이 경우에는 무엇이든 RAM을 사용해야합니다. 데이터 세트를 포함하기에 충분한 RAM이 있어야합니다. RAM이 충분 swap하지 않으며 OS가 사용할 것으로 생각합니다. 아주 좋은 생각은 아닙니다.

컴퓨터 시스템에는 많은 캐시 계층이 있습니다. API와 데이터베이스 쿼리를 캐싱하면 응용 프로그램 계층에 하나를 삽입하는 것이 유리할 수 있습니다. 그리고 아마도 사용자 세션과 같은 임시 데이터.

Redis와 같은 데이터 저장소는 데이터베이스를 사용하는 것처럼 네트워크 (빠른) 또는 UNIX 소켓 (보다 빠른)을 통해 이러한 서비스를 제공합니다.

애플리케이션의 실제 성능을 측정해야하지만 예제를 만들어 봅시다. 일반적인 사용자 요청이 각각 50ms가 걸리는 5 개의 API 쿼리를 수행한다고 가정합니다. 250ms는 사용자 감지 대기 시간입니다. 결과 캐싱과 대조됩니다. 캐시가 도시 전체의 다른 가용 영역에 있더라도 (최적이 아님) 적중은 최대 10ms 일 수 있습니다. 이것은 5 배의 속도 향상입니다.

실제로 데이터베이스 및 스토리지 시스템에는 자체 캐시도 있습니다. 그러나 일반적으로 데이터베이스 엔진과 스토리지 시스템 계층을 다시 통과하는 것보다 미리 가져온 결과를 얻는 것이 더 빠릅니다. 또한 캐싱 계층은 뒤에있는 데이터베이스에서 상당한로드를 제거 할 수 있습니다.

프로덕션에서 이러한 캐시의 예를 보려면 아키텍처에 대한 스택 오버플로 인프라 블로그를 살펴보십시오 . 수십억 건의 Redis 적중을 발생시키는 수십만 건의 HTTP 요청이 상당히 중요합니다.

메모리가 비싸다.

100ns 액세스 시간의 DRAM은 솔리드 스테이트 영구 스토리지보다 약 100 배 빠릅니다. 이 성능은 상대적으로 저렴합니다. 많은 응용 프로그램의 경우 약간 더 많은 RAM이 소중한 속도와 응답 시간을 구입합니다.