NCache 성능 벤치 마크
2백만 작업/초
(5노드 클러스터)
개요
NCache 선형적으로 확장하고 성과를 쉽고 비용 효율적으로 향상시킬 수 있도록 지원합니다. 전 세계 Fortune 500대 기업들이 신뢰해 왔습니다. NCache 13년 이상 데이터 저장 및 데이터베이스와 관련된 성능 병목 현상을 제거하고 .NET 애플리케이션을 극한 트랜잭션 처리(XTP)로 확장하기 위해 노력해 왔습니다.
이 문서는 다음을 사용합니다. NCache .NET 애플리케이션에서 얻을 수 있는 선형 확장성과 극한의 성능을 보여주기 위해 최신 API와 몇 가지 새로운 기능을 갖춘 5.0 버전을 출시했습니다. 이 실험에서는 모뎀을 번들로 제공했습니다. NCache 파이프라인이 활성화된 분할 캐시 토폴로지를 사용하는 API입니다. 데이터는 모든 캐싱 서버에 완전히 분산되며, 클라이언트는 읽기 및 쓰기 요청을 위해 모든 서버에 연결합니다.
이 벤치마크에서 우리는 NCache 클러스터는 선형적으로 확장할 수 있으며 우리가 달성한 2개의 캐시 서버 노드만 사용하여 초당 5백만 트랜잭션. 우리는 또한 그것을 증명할 것입니다 NCache 대규모 클러스터에서도 XNUMX마이크로초 미만의 대기 시간을 제공할 수 있습니다. 이 백서에서는 벤치마크 설정, 벤치마크 수행 단계, 구성 테스트, 로드 구성 및 결과에 대해 다룹니다. 여기에서 벤치마크 실험이 실제로 진행되는 것을 볼 수 있습니다. 비디오.
벤치마크 설정 개요
벤치마크 설정을 살펴보겠습니다. 이 테스트에는 AWS m4.10xlarge 서버를 사용할 것입니다. XNUMX개의 서버가 있습니다. NCache 캐시 클러스터를 구성할 서버입니다. 15개의 클라이언트 서버가 있으며, 이 서버에서 캐시 클러스터에 연결하는 애플리케이션을 실행합니다.
운영 체제로 Windows Server 2016(Data Center Edition, 64비트)을 사용할 예정입니다. NCache 사용 중인 버전은 5.0 Enterprise입니다. 이 벤치마크 설정에서는 분할된 캐시 토폴로지분할 캐시 토폴로지에서는 모든 데이터가 모든 캐싱 서버의 파티션에 완전히 분산됩니다. 또한 모든 클라이언트는 모든 서버에 연결되어 읽기 및 쓰기 요청을 동시에 처리합니다. 이 토폴로지에서는 복제 기능이 활성화되어 있지 않지만, 다음과 같은 다른 토폴로지도 있습니다. 분할된 복제본 토폴로지 복제 지원 기능이 탑재되어 있습니다.
우리는 파이프 라이닝 활성화된 기능은 새로운 기능입니다. NCache 5.0. 클라이언트 측에서 런타임에 발생하는 모든 요청을 누적하여 서버 측에 즉시 적용하는 방식으로 작동합니다. 누적은 마이크로초 단위로 이루어지므로 매우 최적화되어 있으며, 높은 트랜잭션 부하가 필요한 경우 권장되는 구성입니다.
하드웨어, 소프트웨어, 부하 구성을 포함한 벤치마크 설정에 대한 간략한 개요는 다음과 같습니다.
하드웨어 구성 :
| 클라이언트 및 서버 세부 정보 (가상 머신) |
AWS m4.10xlarge: 40개 코어, 160GB 메모리, 네트워크 - 10Gbps 이더넷 |
| 서버 노드 수 | 5 |
| 클라이언트 노드 수 | 15 |
소프트웨어 구성 :
| 운영체제 | 윈도우 서버 2016 데이터 센터 에디션 – x64 |
| NCache 버전 | 5.0 |
| 클러스터 토폴로지 | 분할된 캐시 구성 |
로드 구성 :
| 캐시 크기 | 4 GB |
| 데이터 크기 | 크기가 100인 바이트 배열 |
| 총 항목 | 1,000,000 |
| 파이프 라이닝 | 사용 |
| 비율 가져오기/업데이트 | 80:20 |
| 스레드 | 1280 |
| 애플리케이션 인스턴스 | 클라이언트 머신당 2개의 인스턴스, 총 30개의 인스턴스 |
데이터 채우기
벤치마크 환경 설정 후, 캐시 클러스터에 1만 개의 항목을 데이터로 채웁니다. 클라이언트 애플리케이션(캐시 항목 로더)을 실행하여 캐시에 연결하고 1만 개의 항목을 추가합니다. 한 클라이언트가 모든 캐싱 서버에 연결하여 캐시 클러스터에 1만 개의 항목을 추가합니다. 그 후 읽기 및 쓰기 요청을 시작할 수 있습니다.
이것을 사용할 수 있습니다. Nuget 패키지 – NCache SDK 클라이언트 머신에 SDK를 설치하고 클라이언트-서버 간 파이프라인을 구성하고, 캐시 클러스터에 1만 개의 캐시 항목을 채우기 위해 로드 생성 애플리케이션(GitHub)을 배포합니다.
빌드 트랜잭션 로드
이제 이 캐시 클러스터에 80% 읽기, 20% 쓰기 작업으로 트랜잭션 부하를 구축하기 위해 애플리케이션을 실행하겠습니다. Perfmon 카운터를 사용하여 모든 활동을 모니터링할 수 있습니다. 처음에는 각 인스턴스에 10개의 클라이언트 인스턴스를 연결합니다. NCache 초당 업데이트와 페치에 대한 활동이 있는 서버입니다.
무대 1 1만 Ops/초 트랜잭션 로드
스크린샷에서 10노드 클러스터에 5개의 클라이언트 인스턴스가 연결되어 있는 것을 볼 수 있습니다. 초당 요청 수는 180,000에서 190,000 사이입니다. 그리고 5개의 NCache 병렬로 작동하는 서버가 이러한 요청을 누적하면 이 캐시 클러스터에서 초당 1만 개의 요청이 처리됩니다.
메모리와 CPU 사용량이 효율적이며, 평균 마이크로초/캐시 연산은 연산당 10마이크로초 미만입니다. 1단계가 완료되어 캐시 클러스터에서 초당 XNUMX만 건의 연산을 달성했습니다.
| 1단계 – 요약 데이터 시트 | |
| 클러스터의 총 캐시 서버 | 5 |
| 연결된 총 클라이언트 인스턴스 | 10 |
| 초당 요청 수/노드 | 180,0000 ~ 190,000 |
| 총 요청 - 캐시 클러스터 | 950,000 ~ 1,000,000 |
| % 프로세서 시간(최대) | 20% |
| 시스템 메모리 | 4.2 GB |
| 지연 시간(마이크로초/캐시 작업) | 10마이크로초/작업 |
무대 2 1.5만 Ops/초 트랜잭션 로드
이제 1만 TPS를 달성했으니, 트랜잭션 부하를 늘리기 위해 애플리케이션 인스턴스를 늘려야 합니다. 애플리케이션이 실행되면 초당 요청 수(RPS) 카운터가 증가하는 것을 확인할 수 있습니다. 클라이언트 수를 20개로 늘릴 예정입니다. 이 구성을 사용하면 아래 스크린샷에서 인스턴스당 초당 300,000만 건의 요청이 표시되는 것을 확인할 수 있습니다. 이 캐시 클러스터에서 초당 1.5만 건의 요청을 성공적으로 달성했습니다.
각 서버의 초당 요청 수가 300,000만 건인 것을 확인할 수 있습니다. 페치는 초당 200,000만 건을 조금 넘고, 업데이트는 50,000만 건에서 100,000만 건 사이이며, 캐시 작업당 평균 마이크로초는 4마이크로초 미만입니다. 파이프라인의 영향과 함께 지연 시간이 매우 낮다는 점을 고려하면 놀라운 결과입니다. 클라이언트 측에서 트랜잭션 부하가 높을 때 파이프라인은 지연 시간을 줄이고 처리량을 높이는 데 큰 도움이 됩니다. 따라서 파이프라인을 활성화하는 것이 좋습니다. 또한, 현재 캐시 작업당 평균 마이크로초는 약 3~4마이크로초입니다.
| 2단계 – 요약 데이터 시트 | |
| 클러스터의 총 캐시 서버 | 5 |
| 연결된 총 클라이언트 인스턴스 | 20 |
| 초당 평균 요청 수/노드 | 300,000 |
| 총 요청 - 캐시 클러스터 | 1,500,000 |
| % 프로세서 시간(최대) | 30% |
| 시스템 메모리 | 6 GB |
| 지연 시간(마이크로초/캐시 작업) | 3 ~ 4 마이크로초/작업 |
무대 3 2만 Ops/초 트랜잭션 로드
애플리케이션 인스턴스를 더 실행하여 부하를 더욱 높여 보겠습니다. 그러면 초당 요청 수도 더욱 증가할 것입니다. 이제 30개의 클라이언트 인스턴스를 모든 NCache 서버.
아래 스크린샷에 따르면 이제 우리는 초당 400,000개의 요청을 성공적으로 처리했으며 이는 각각에서 얻고 있습니다. NCache 서버; 우리는 5개 있습니다 NCache 서버이므로 이를 통해 초당 최대 200만 건의 거래가 가능합니다. NCache 캐시 클러스터입니다. 캐시 작업당 평균 마이크로초는 3마이크로초 미만입니다. 또한 시스템 메모리와 프로세서 시간은 두 가지 모두 40~50%의 사용률을 기록하며 한계치를 크게 밑돌고 있습니다.
이제 작업당 2~3us의 지연 시간이 발생하여 이전 결과보다 개선되었습니다. 페치, 업데이트, 그리고 CPU 및 메모리 리소스의 효율적인 활용이 다시 한번 확인됩니다. 결론적으로 다음과 같습니다. NCache 선형적으로 확장 가능합니다. 이제 확장성 수치를 살펴보겠습니다.
| 3단계 – 요약 데이터 시트 | |
| 클러스터의 총 캐시 서버 | 5 |
| 연결된 총 클라이언트 인스턴스 | 30 |
| 초당 평균 요청 수/노드 | 400,000 |
| 총 요청 - 캐시 클러스터 | 2,000,000 |
| % 프로세서 시간(최대) | 60% |
| 시스템 메모리 | 6 GB |
| 지연 시간(마이크로초/캐시 작업) | 2 ~ 3 마이크로초/작업 |
벤치 마크 결과
우리는 그것을 증명할 수 있었습니다 NCache 선형적으로 확장 가능하며 벤치마크를 실행한 후 다음과 같은 결과를 얻을 수 있었습니다.
결론
- 선형 확장성: 5개로 NCache 서버를 추가하면 초당 2만 건의 요청을 처리할 수 있었습니다. 서버를 더 많이 추가할수록 요청 처리 용량이 더 커집니다. NCache.
- 낮은 지연 시간 및 높은 처리량: NCache 대규모 클러스터 크기에도 불구하고 서브 마이크로초(2.5~3 마이크로초) 지연 시간을 제공합니다. NCache 대규모 환경에서도 낮은 지연 시간과 높은 처리량 요구 사항을 충족하는 데 도움이 됩니다. 파이프라인을 통해 얻은 효과 덕분에 지연 시간이 매우 낮습니다. 클라이언트 측에서 트랜잭션 부하가 많을 때 파이프라인은 지연 시간을 줄이고 처리량을 높이는 데 큰 도움이 됩니다.