NCache 성능 벤치 마크

NCache 벤치마크 그래프

실제 벤치마킹 비디오를 시청하여 이러한 벤치마크가 어떻게 수행되었는지 확인할 수 있습니다.

이 영상에서는 다음에 대해 이야기하겠습니다. NCache 성과 벤치마킹 수치. NCache 매우 빠르고 확장 가능합니다 메모리 내 분산 캐싱 귀사의 .NET 및 .NET Core 애플리케이션을 위한 시스템이며, 오늘 우리는 단 5개의 모듈만으로 초당 2만 건의 작업을 처리하고 동시에 작업당 3마이크로초 미만의 지연 시간을 유지할 것입니다. NCache 서버.

NCache 이 지점을 넘어서면 선형적으로 확장 가능하므로 필요한 만큼 많은 서버를 추가할 수 있으며 서버를 더 추가할수록 요청 처리 용량도 더 많아집니다. 캐시 클러스터 그것도 선형적으로 말이죠.

벤치마크 설정

벤치마크 설정을 살펴보겠습니다. 테스트에는 'AWS m4xlarge' 서버를 사용하고 있습니다. 이 서버가 10개 있습니다. NCache 캐시 클러스터가 구성된 서버와 15개의 클라이언트 서버가 있는데, 여기서 애플리케이션을 실행하고 이 캐시 클러스터에 연결합니다.

저는 Windows Server 2016을 운영 체제로 사용하고 있으며, Data Center Edition 64비트를 사용하고 있습니다. NCache 버전은 5.0 Enterprise이고 사용 중입니다. NCache 파티션된 캐시캐싱 토폴로지로서.

캐싱 토폴로지

이 토폴로지의 아키텍처 다이어그램은 모든 캐싱 서버에 데이터가 파티션으로 완전히 분산되어 있고, 클라이언트가 읽기 및 쓰기 요청을 위해 모든 서버에 연결하는 것을 보여줍니다. 클라이언트는 모든 서버를 동시에 최대한 활용합니다. 이 토폴로지에서는 복제 기능을 활성화하지 않았지만, 다음과 같은 다른 토폴로지도 있습니다. 분할된 복제본 캐시복제 지원 기능도 갖추고 있습니다.

벤치마크 환경 구성

내가 가진 파이프 라이닝 활성화됨. 새로운 기능입니다. NCache 버전 5.0입니다. 클라이언트 측에서 런타임에 발생하는 모든 요청을 누적하여 서버 측에 즉시 적용하는 방식으로 작동합니다. 누적은 마이크로초 단위로 이루어집니다. 따라서 매우 최적화되어 있으며, 높은 트랜잭션 부하가 필요한 경우 설정 또는 구성에 매우 권장됩니다.

부하 구성과 관련하여, 총 1만 개의 항목을 사용하고 있으며, 이 항목들은 캐시에 추가될 예정입니다. 그런 다음 캐시에서 읽기 80%, 쓰기 20% 비율로 읽기 및 쓰기 요청 부하를 시뮬레이션합니다. 또한, 캐시에 개별 항목으로 각각 100개의 바이트 배열을 사용합니다. 서버당 4GB 캐시 크기를 사용하고, 캐시에 연결할 총 30개의 애플리케이션 인스턴스를 사용합니다.

데이터 채우기

따라서 지연 없이 내 1만 개 항목의 '데이터 채우기'를 시작하겠습니다. 캐시 클러스터. 이제 데모 환경입니다. 5개가 있습니다. NCache 앞서 설명한 대로 서버입니다. 현재 아무런 활동이 없지만, 캐시에 연결하여 1만 개의 항목을 추가하는 클라이언트 애플리케이션을 시뮬레이션해 보겠습니다.

애플리케이션을 실행했더니 모든 캐싱 서버에 클라이언트 1개가 연결된 것을 볼 수 있었고, 모든 서버의 초당 추가 카운터에도 활동이 있었습니다. 캐시 크기와 개수 카운터도 증가하고, 초당 요청 수는 초당 총 요청 수를 나타냅니다. 자, 캐시 클러스터에 이미 백만 개의 항목이 추가되었습니다. 이제 읽기 및 쓰기 요청 부하를 측정할 수 있습니다. 모니터링 세부 정보를 간략하게 보여드리면 CPU, 메모리, 초당 추가, 초당 요청 수, 개수 카운터가 조금씩 증가하는 것을 볼 수 있습니다. 캐시 크기도 증가했습니다.

트랜잭션 로드 구축

이제 이 캐시 클러스터에 80% 읽기, 20% 쓰기 작업으로 트랜잭션 부하를 구축하는 애플리케이션을 실행하겠습니다. 자, 빠르게 실행해 보겠습니다. 그러면 모든 캐시 서버에서 PerfMon 카운터의 활동이 표시되기 시작할 것입니다.

초당 1만 건의 요청

클라이언트 카운터 수를 볼 수 있는데, 여기에는 각각에 연결된 인스턴스가 약 10개 정도 표시됩니다. NCache 서버의 Fetches(페치) 및 Updates(초당 업데이트) 활동과 Requests(초당 요청) 카운터는 초당 180,000건에서 190,000건 사이입니다. 그리고 5개가 있으므로 NCache 병렬로 작동하는 서버이므로 이러한 요청을 누적하면 이 캐시 클러스터에서 초당 1만 개의 요청이 발생하고 매우 일관된 것을 볼 수 있습니다. 데이터 배포.

웹 모니터링 통계는 꽤 양호합니다. 시스템 메모리와 CPU는 상당히 낮고, 초당 페치(Fetch)와 초당 요청(Request)은 초당 200,000만 건, 페치(Fetch)는 초당 약 150,000만 건입니다. 업데이트는 초당 50,000만 건입니다. 캐시 작업당 평균 마이크로초(μs)는 작업당 10마이크로초 미만입니다. 이 캐시 클러스터의 가장 큰 장점은 메모리 내(In-Memory) 방식으로 낮은 지연 시간과 높은 처리량을 보장한다는 것입니다. NCache 캐시 클러스터.

1단계는 완료되었으며, 캐시 클러스터에서 초당 200,000만 건의 작업을 성공적으로 처리했습니다. 참고용 스크린샷을 첨부했는데, 각 클러스터에서 초당 XNUMX만 건의 요청이 처리되고 있습니다. NCache 서버와 우리는 이런 것을 5개 가지고 있습니다 NCache 서버는 캐시당 10마이크로초 미만의 운영 지연 시간을 유지합니다.

따라서 작업당 속도가 매우 빠르고 초당 가져오기와 업데이트의 혼합도 비교적 일관적이어서 실제 애플리케이션 시나리오를 보여주고 동시에 CPU와 메모리를 매우 효율적으로 활용합니다. 이 특정 테스트에서는 이러한 리소스의 활용도가 매우 낮습니다.

1.5만 건의 요청/초

이제 초당 1만 건의 요청을 달성했으니 부하를 늘려야 합니다. 따라서 트랜잭션 부하를 늘리기 위해 애플리케이션 인스턴스를 몇 개 더 실행하고, 이러한 애플리케이션이 실행되면 초당 요청 카운터가 증가하는 것을 확인할 수 있습니다.

우선 클라이언트 수가 20개라는 것을 알 수 있습니다. 모든 인스턴스에 연결된 20개의 인스턴스입니다. NCache 서버와 초당 요청 카운터가 현재 각각 초당 300,000개의 요청을 표시하고 있습니다. NCache 서버를 통해 이 캐시 클러스터에서 초당 1.5만 건의 요청을 성공적으로 달성했습니다.

잠깐 보여드리죠 웹 모니터링 도구성능 통계를 보려면 각 서버의 초당 요청 수를 확인하세요. 초당 요청 수는 300,000만 건입니다. 페치는 초당 200,000만 건을 약간 넘고 업데이트는 50,000만 건에서 100,000만 건 사이입니다. 캐시 작업당 평균 마이크로초(μs)는 4마이크로초 미만입니다. 지연 시간이 매우 짧기 때문에 놀라운 수치이며, 이는 '파이프 라이닝'. 클라이언트 측에서 높은 트랜잭션 부하가 발생할 때 파이프라인은 매우 효과적이며 지연 시간을 줄이고 처리량을 증가시킵니다. 바로 이러한 이유로 파이프라인을 활성화하는 것이 좋습니다.

1.5단계가 완료되어 캐시 클러스터에서 초당 XNUMX만 건의 작업을 처리했습니다. 이 결과의 스크린샷은 다음과 같습니다.

이제 우리는 각각 초당 300,000개의 요청을 가지고 있습니다. NCache 서버. 서버 용량이 증가했고, 지연 시간도 감소했습니다. 캐시 작업당 평균 마이크로초(μs)가 소요되던 것이 이제는 캐시 작업당 약 3~4마이크로초가 소요됩니다. 엄청난 개선입니다. 페치와 업데이트가 적절히 섞여 있고, CPU와 메모리 사용량도 줄었습니다. 현재 서버 용량이 최대치에 도달한 것은 아닙니다. 부하를 더 늘릴 수 있다는 점을 명확히 하고 싶습니다. 다음 단계에서 자세히 설명드리겠습니다.

2만 건의 요청/초

초당 1.5만 건의 요청을 달성한 후에도 여기서 멈추지 않겠습니다. 부하를 더 높여서 어떻게 되는지 살펴보겠습니다. NCache 캐시 클러스터가 그 결과로 작동합니다. 따라서 애플리케이션 인스턴스를 더 실행하면 초당 요청 수 카운터가 더욱 증가하는 것을 볼 수 있습니다. 30개의 클라이언트가 표시되고 인스턴스가 이제 모든 클라이언트에 연결되었습니다. NCache 서버와 초당 요청 카운터가 이미 증가하고 있습니다.

이제 각 요청이 초당 400,000건의 요청을 성공적으로 처리한 것을 볼 수 있습니다. NCache 서버. 그리고 우리는 5개 NCache 서버, 따라서 이것으로 초당 총 2만 개의 요청이 발생합니다. NCache 캐시 클러스터. 따라서 클라이언트 측에서 트랜잭션 부하를 늘리면 다음과 같은 결과를 명확하게 확인할 수 있습니다. NCache 초당 2만 건의 요청을 처리했습니다. 캐시 작업당 평균 마이크로초(μs)는 3마이크로초 미만이며, 시스템 메모리와 프로세서 시간도 제한을 크게 넘지 않습니다. CPU 사용률은 두 가지 모두 40%에서 50% 수준입니다.

보시다시피, 초당 2만 건의 연산을 성공적으로 달성했습니다. 스크린샷을 통해 결과를 확인해 보겠습니다.

이제 우리는 각각 초당 400,000개의 요청을 가지고 있습니다. NCache 서버는 초당 총 2만 건의 요청을 처리하며, 좋은 점은 지연 시간이 더욱 단축되었다는 것입니다. 이제 캐시 작업당 2~3마이크로초의 지연 시간이 발생하는데, 이는 이전 결과보다 개선된 것입니다. Fetch와 Update가 혼합되어 있고 CPU와 메모리 리소스도 매우 효율적으로 사용되는 것을 다시 확인할 수 있습니다.

그리고 내가 말했듯이, NCache is 선형 확장 가능, 그럼 확장성 수치를 살펴보죠. 아시다시피, 서버 수를 늘리면 NCache 꽤 선형적으로 확장됩니다. 5개로 NCache 서버를 통해 초당 2만 건의 요청을 달성할 수 있었고, 점점 더 많은 서버를 추가할 수 있으며 이러한 추세는 더욱 선형적이 될 것입니다. 즉, 서버가 많을수록 요청 처리 용량도 더 커집니다. NCache.

맺음말

영상은 여기까지입니다. 모든 테스트 결과와 샘플 애플리케이션은 저희 웹사이트에서 확인하실 수 있으며, 직접 다운로드하여 사용 환경에서 확인해 보실 수 있습니다. 궁금한 점이 있으시면 언제든지 영업팀(sales@alachisoft.com) 그리고 우리의 지원과 함께 (support@alachisoft.com) 팀 여러분, 시간 내주셔서 감사합니다.