NCache 성능 벤치 마크

NCache 벤치마크 그래프

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

이 비디오에서 우리가 이야기할 NCache 성능 벤치마킹 수치. NCache 매우 빠르고 확장 가능합니다. 메모리 내 분산 캐싱 .NET용 시스템 및 .NET Core 현재 우리는 초당 2백만 작업을 달성하는 동시에 작업당 3마이크로초 미만의 대기 시간을 유지하면서 단 5 NCache 서버.

NCache 이 지점 이상으로 선형 확장 가능합니다. 즉, 필요한 만큼 서버를 추가할 수 있으며 서버를 더 추가하는 동안 더 많은 요청 처리 용량을 얻을 수 있습니다. 캐시 클러스터 그것도 선형 방식으로.

벤치마크 설정

벤치마크 설정을 검토해 보겠습니다. 저는 'AWS m4. 내 테스트를 위한 10xlarge의 서버. 나는 이 다섯 가지를 가지고 있다. NCache 내 캐시 클러스터가 구성되어 있고 15개의 클라이언트 서버가 있는 서버에서 애플리케이션을 실행하고 이 캐시 클러스터에 연결합니다.

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

캐싱 토폴로지

모든 캐싱 서버와 클라이언트가 읽기 및 쓰기 요청을 위해 모든 서버에 연결하는 파티션에 데이터가 완전히 분산되어 있는 이 토폴로지의 아키텍처 다이어그램입니다. 그들은 동시에 모든 서버를 완전히 활용합니다. 이 토폴로지에 대해 복제가 설정되어 있지 않지만 다음과 같은 다른 토폴로지가 있습니다. 분할된 복제본 캐시, 복제 지원도 함께 제공됩니다.

벤치마크 환경 구성

내가 가진 파이프 라이닝 활성화됨. 의 새로운 기능입니다. NCache 버전 5.0. 클라이언트 측에서 런타임에 발생하는 모든 요청을 누적하고 서버 측에서 해당 요청을 한 번에 적용하고 누적이 마이크로초 내에 수행되는 방식으로 작동합니다. 따라서 매우 최적화되어 있으며 트랜잭션 로드 요구 사항이 높을 때 매우 권장되는 설정 또는 구성입니다.

로드 구성과 관련하여 우리는 캐시에 추가될 총 1만 개의 항목을 사용하고 있으며 80% 읽기 및 20% 쓰기 비율로 읽기 및 쓰기 요청 로드를 시뮬레이션합니다. 캐시. 그리고 Cache의 개별 항목으로 각각 100개의 Byte 배열이 있습니다. 서버당 캐시 크기가 4GB이고 캐시에 연결할 총 30개의 애플리케이션 인스턴스가 있습니다.

데이터 채우기

그래서 지체 없이 내 1만 항목의 '데이터 채우기'를 시작하겠습니다. 캐시 클러스터. 이제 이것이 데모 환경입니다. 우리는 5 NCache 앞에서 설명한 것처럼 서버. 현재는 활동이 없지만 연결하고 캐시에 1만 항목을 추가할 클라이언트 응용 프로그램을 시뮬레이션하겠습니다.

따라서 응용 프로그램을 실행했으며 모든 캐싱 서버에 연결된 1개의 클라이언트를 볼 수 있으며 모든 서버에서 초당 추가 카운터에 대한 활동이 있습니다. 캐시 크기가 증가하고 카운트 카운터도 증가하고 초당 요청은 초당 총 요청 수입니다. 그리고 캐시 클러스터에 이미 1만 개의 항목이 추가되었습니다. 이제 읽기 및 쓰기 요청 로드를 시작할 수 있습니다. 모니터링 세부 정보를 빠르게 표시하면 CPU, 메모리, 초당 추가 수 및 초당 요청 수 및 카운트 카운터에서도 캐시 크기가 증가했습니다.

트랜잭션 로드 구축

이제 응용 프로그램을 실행하여 80% 읽기 및 20% 쓰기 작업으로 이 캐시 클러스터에 트랜잭션 로드를 구축하겠습니다. 자, 빨리 합시다. 그리고 PerfMon 카운터의 모든 캐시 서버에서 활동을 보기 시작할 것입니다.

1만 요청/초

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

웹 모니터링 통계는 시스템 메모리 및 CPU가 매우 낮고 매우 낮으며 초당 가져오기 및 초당 요청으로 초당 200,000 요청, 초당 약 150,000 가져오기를 보여 주는 매우 건강합니다. 업데이트는 초당 50,000 업데이트입니다. 그리고 캐시 작업당 평균 마이크로초는 작업당 10마이크로초 미만입니다. 그리고 이것이 인메모리에 있는 이 캐시 클러스터의 가장 좋은 점입니다. 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 사이입니다. 그리고 캐시 작업당 평균 마이크로초가 4마이크로초 미만인 것을 볼 수 있습니다. 지연 시간이 매우 짧고 이것이 '파이프 라이닝'. 클라이언트 측에서 트랜잭션 부하가 높을 때 파이프라이닝은 실제로 도움이 되고 대기 시간을 줄여 처리량을 증가시킵니다. 이것이 바로 이 기능을 켜도록 권장할 수 있는 이유입니다.

이제 1.5단계가 완료되어 캐시 클러스터에서 초당 XNUMX만 작업을 달성했습니다. 다음은 이 결과에 대한 스크린샷입니다.

이제 초당 300,000개의 요청이 있습니다. NCache 섬기는 사람. 그래서 그것이 증가했고 지연 시간이 감소했습니다. 우리는 캐시 작업당 평균 마이크로초를 얻었으며 이제 캐시 작업당 약 3~4마이크로초가 소요됩니다. 따라서 이는 엄청난 개선이며, Fetches와 Update가 꽤 혼합되어 있고 CPU와 메모리의 사용률을 낮추는 유지 관리가 있습니다. 따라서 이 시점에서 서버가 최대치에 도달하지 않았습니다. 나는 당신이 하중을 더 늘릴 수 있다는 것을 분명히 하고 싶습니다. 이것은 우리가 다음에 할 것입니다.

2만 요청/초

초당 1.5만 요청을 달성한 후, 저는 여기서 멈추지 않을 것입니다. 부하를 더 높이고 어떻게 되는지 봅시다. NCache 그 결과 캐시 클러스터가 작동합니다. 그래서 더 많은 애플리케이션 인스턴스를 실행하고 있으며 초당 요청 카운터가 더 증가하는 것을 볼 수 있습니다. 30개의 클라이언트를 볼 수 있습니다. 이제 인스턴스가 모든 클라이언트에 연결되어 있습니다. NCache 서버 및 우리는 이미 초당 요청 카운터의 증가를 보고 있습니다.

이제 우리가 성공적으로 초당 400,000개의 요청을 처리했음을 알 수 있습니다. NCache 섬기는 사람. 그리고 우리는 5 NCache 서버, 따라서 초당 총 2백만 요청을 생성합니다. NCache 캐시 클러스터. 따라서 Client-end에서 트랜잭션 로드를 증가시키면 명확하게 볼 수 있습니다. NCache 초당 2백만 요청을 달성했습니다. 그리고 캐시 작업당 평균 마이크로초가 3마이크로초 미만이며 시스템 메모리 및 프로세서 시간도 있습니다. CPU는 한계에 훨씬 못미칩니다. 여기서 저는 두 가지 측면에서 모두 40%에서 50%의 활용률을 보입니다.

이제 보다시피 초당 2만 작업을 성공적으로 달성했습니다. 따라서 스크린샷을 통해 이러한 결과를 검토해 보겠습니다.

이제 초당 400,000개의 요청이 있습니다. NCache 초당 총 2만 요청을 하는 서버인데 레이턴시가 더 떨어졌다. 이제 캐시 작업 대기 시간당 2~3마이크로초가 있으며 이는 이전 결과에서 다시 개선된 것입니다. 다시 한 번 가져오기와 업데이트가 혼합되어 있고 CPU와 메모리 리소스를 매우 효율적으로 활용하는 것을 볼 수 있습니다.

그리고 내가 말했듯이, NCache is 선형 확장 가능, 따라서 확장성 수치를 검토해 보겠습니다. 서버 수를 늘리면 알 수 있습니다. NCache 꽤 선형적인 방식으로 확장됩니다. 5와 함께 NCache 서버에서 초당 2만 요청을 달성할 수 있었고 더 많은 서버를 추가할 수 있으며 이러한 추세는 더 선형적입니다. 여기서 더 많은 서버는 더 많은 요청 처리 용량을 의미합니다. NCache.

결론

이것은 우리를 비디오의 끝으로 인도합니다. 이러한 모든 테스트 결과와 샘플 응용 프로그램은 웹 사이트에서 사용할 수 있으며 사용자 환경에서 다운로드하여 직접 검토할 수 있습니다. 질문이 있으시면 언제든지 저희 영업팀에 연락해 주십시오(sales@alachisoft.com) 뿐만 아니라 우리의 지원(support@alachisoft.com) 팀. 시간 내 주셔서 정말 감사합니다.