최적화하는 XNUMX가지 방법 NCache 퍼포먼스
녹화된 웨비나
칼 알리와 샘 아완
NCache .NET용으로 널리 사용되는 오픈 소스 인메모리 분산 캐시입니다. 애플리케이션 데이터를 캐싱하고 값비싼 데이터베이스 이동을 줄여 .NET 애플리케이션을 확장하는 데 도움이 됩니다. NCache 캐싱 계층 클러스터에 더 많은 캐시 서버를 추가할 수 있어 선형적으로 확장됩니다.
최적화 방법 알아보기 NCache 적절하게 구성하고 성능 향상 기능을 사용하여 성능을 향상시킵니다.
이 웨비나는 다음 내용을 다룹니다.
- 장점 소개 NCache 그리고 그 건축
- 일반적인 방법 NCache 사용
- NCache 성능 향상 기능
- NCache 성능 향상 구성 옵션
살펴보기
오늘 우리는 XNUMX가지 방법에 대한 웨비나를 발표할 것입니다. NCache 성능. 이 웨비나의 모드는 듣기 전용입니다. 원하는 모든 유형의 질문을 할 수 있습니다. 오른쪽 창에 질문 및 답변 탭이 있습니다. 질문을 입력하시면 저희 중 한 명이 해당 질문에 답변해 드릴 것입니다. 웨비나 중에 질문이나 우려 사항이 있고 우리의 말을 들을 수 없는 경우 다시 채팅 창을 사용할 수 있습니다. Kal은 프레젠테이션의 모든 기술적인 부분에 대해 이야기할 것입니다. 기술이나 영업과 관련되지 않은 것이 있으면 질문을 저에게 직접 보낼 수 있습니다. 그 말을 하고 나는 그것을 Kal에게 넘겨주고 그는 프레젠테이션을 시작할 것입니다.
괜찮은. 샘 감사합니다. 방금 공유를 시작했기 때문에 내 화면을 볼 수 있는지 확인해 주시겠습니까? 예, 귀하의 화면을 완벽하게 볼 수 있습니다. 좋아, 완벽해. 안녕하세요, Sam이 방금 저를 소개했을 때 제 이름은 Kal이고 오늘 웨비나의 주제는 최적화하는 XNUMX가지 방법입니다. NCache 공연.
따라서 오늘의 웨비나에서는 NCache 또한 성능을 최적화하기 위해 애플리케이션 내에서 사용할 수 있는 기능. 그래서, NCache 이미 성능 솔루션입니다. 데이터베이스로 이동하는 횟수가 줄어들기 때문에 애플리케이션의 성능이 빠르게 향상됩니다. 그러나 이러한 기능을 사용하면 실제로 더 개선할 수 있으며 이 XNUMX가지 트릭은 실제로 사용 사례 기반이 될 것입니다. 저는 각각의 사용 사례와 함께 사용 사례를 제시할 예정이며 특정 시나리오에 적용되는 것을 기반으로 하여 확실히 사용하고 이것이 어떻게 작동하는지 확인할 수 있습니다. 따라서 다양한 응용 프로그램의 실제 실습을 다룰 것이며 이에 따라 다양한 상황에서 어떻게 되는지 볼 것입니다. NCache 작동하고 이러한 기능이 실제로 우리에게 어떻게 도움이 되는지. 그럼 지금부터 발표를 진행하겠습니다.
확장성 문제
따라서 우선 대부분의 배포 시나리오에서 볼 수 있는 확장성 문제에 대해 실제로 이야기해 보겠습니다. 따라서 일반적으로 웹 팜이 있습니다. 로드 밸런서 이러한 종류의 계층에서 이 시나리오는 일반적으로 매우 확장 가능합니다. 애플리케이션에 더 많은 부하가 가해지는 것을 알 수 있듯이 기본적으로 이 계층에 더 많은 서버를 추가할 수 있으며 이는 실제로 수용할 수 있는 총 부하 측면에서 환경의 용량을 증가시킬 것입니다. 예를 들어 XNUMX초에 처리할 수 있는 총 요청 수입니다.
실제 문제인 실제 병목 현상은 이러한 애플리케이션이 백엔드 데이터 소스와 연결되어야 하는 위치에 있습니다. 참조 데이터를 얻기 위해, 거기에 저장된 다른 종류의 데이터를 얻기 위해서일 수도 있습니다. 그래서, 기본적으로 그것이 병목 현상이 있는 곳입니다. 일반적으로 백엔드 데이터 소스는 데이터베이스입니다. 우리 모두 알다시피 데이터베이스는 저장에 탁월하지만 문제는 디스크에 있기 때문에 일반적으로 느립니다. 높은 트랜잭션 부하에서 질식하는 경향이 있으며 확장성이 좋지 않습니다.
솔루션
따라서 이러한 시나리오에서 회사/조직은 다음으로 이동하는 경향이 있습니다. NoSQL database하지만 현재로서는 최적의 접근 방식이 아닙니다. 서로 호환되도록 하려면 애플리케이션 내에서뿐만 아니라 실제 데이터 내에서도 전체 아키텍처 변경이 필요하기 때문입니다. 따라서 이러한 시나리오에서 최적의 접근 방식은 다음과 같은 메모리 내 분산 캐시입니다. NCache, 모든 것이 메모리 내에 배치되기 때문에 더 빠르고 확장 가능합니다. 따라서 데이터베이스와 비교하면 디스크에 존재합니다. 자, 이제 우리는 메모리 안에 존재하는 모든 것을 가지고 있습니다. 분산 캐시는 논리적으로 단일 단위이지만 그 아래에는 이 클러스터 캐시를 호스팅하는 여러 독립 서버가 있기 때문에 확장성이 더 높습니다.
매우 확장 가능한 토폴로지입니다. 여기에 원하는 만큼 서버를 추가할 수 있습니다. 아시다시피, 기본적으로 이러한 모든 서버의 메모리 리소스뿐만 아니라 이러한 모든 리소스의 계산 능력을 풀링합니다. 따라서 더 많은 수의 서버를 추가할수록 저장할 수 있는 총 데이터 측면에서 캐시 용량이 늘어납니다. 또한 총 작업 또는 총 부하가 걸릴 수 있습니다.
따라서 웹 팜에 더 많은 부하가 들어오는 것을 확인하면 실제로 캐싱 클러스터의 서버 수를 늘릴 수 있으며 이는 실제로 이 계층도 확장 가능하게 만듭니다. 따라서 이제 캐싱 계층이 웹 팜에서 들어오는 요청과 일치합니다. 따라서 이제 데이터베이스에 존재했던 비 확장성 부분을 제거하는 데 실제로 도움이 됩니다. 이것의 가장 좋은 점은 데이터베이스를 대체할 수 없다는 것입니다. 함께 사용하시면 됩니다. 따라서 기본적으로 캐시 클러스터는 애플리케이션과 데이터베이스 사이에 위치합니다. 여전히 직접 전화를 걸 수 있습니다. 그러나 그것이하는 일은 당신이 할 수 있다는 것입니다. NCache 데이터의 유일한 소스이며 이 캐시와 함께 제공되는 데이터 액세스 계층 기능이 있습니다. 이를 통해 캐시는 실제로 백엔드 데이터 소스에 데이터를 쓰고 백엔드에서 데이터를 가져올 수 있습니다. 데이터 소스.
따라서 이를 사용하면 캐시가 백엔드 데이터 소스와 동기화된 상태를 유지합니다. 따라서 메모리 내에 존재하고 확장 가능한 소스이기 때문에 더 빠른 소스의 최신 데이터를 갖게 됩니다. 따라서 이 경우에는 매우 좋은 절충안입니다.
NCache 전개
자, 그럼 에 대해 이야기해 봅시다 NCache 이 다이어그램의 배포. 따라서 여기에서 볼 수 있는 경우 기본적으로 응용 프로그램을 호스팅하는 웹 서버 또는 응용 프로그램 서버입니다. 일반적으로 로드 밸런서 뒤에 있습니다. 이전에는 데이터베이스와 같은 백엔드 데이터 소스를 직접 호출했지만 지금은 여기에 캐싱 계층이 있습니다. 이것은 클러스터된 캐시를 호스팅하는 전용 캐싱 계층이 있다는 것입니다.
따라서 애플리케이션이 수행하는 작업은 NCache 데이터의 유일한 소스. 데이터 가져오기 또는 일종의 처리에 대한 모든 요청은 캐시에서 직접 수행되며 캐시에 해당 데이터 액세스 계층 공급자를 사용하여 캐시가 없으면 실제로 데이터 소스에서 다시 가져올 수 있습니다. 이것이 바로 여러분의 환경 내에서 하는 일입니다. 이 서버는 앞서 언급했듯이 전용 서버로 권장되며 매우 저렴한 서버입니다. 유일한 전제 조건 NCache 이 경우는 단지 .NET framework. 클러스터 캐시를 호스팅하는 이러한 서버에는 클러스터 캐시를 호스팅할 수 있는 기능이 있는 캐시 서버가 설치되어 있고 클라이언트에는 애플리케이션 서버인 이 클라이언트 상자가 있습니다. remote client 로컬 캐시를 호스팅할 수 있고 실제로 원격 클러스터 캐시에 연결하는 데 도움이 될 수 있습니다.
배포는 이렇게 생겼습니다. 이 모든 것은 선형적으로 확장 가능합니다. 더 많은 수의 서버를 추가함에 따라 캐시의 총 용량을 늘립니다.
세 가지 일반적인 용도 NCache
세 가지 일반적인 용도에 대해 이야기합시다. NCache. 이 XNUMX가지 방법에 대해 자세히 알아보고 질문이 있으면 확실히 대답할 수 있도록 이 모든 것을 빠르게 진행하고 있습니다. 그럼, 세 가지 일반적인 용도에 대해 이야기해 보겠습니다. NCache.
-
애플리케이션 데이터 캐싱
첫 번째는 애플리케이션 데이터 캐싱입니다. 따라서 이 슬라이드에서 우리는 세 가지 일반적인 용도에 대해 이야기했습니다. NCache. 첫 번째는 애플리케이션 데이터 캐싱입니다. 이 경우 기본적으로 수행하는 작업은 NCache 애플리케이션 내의 API와 해당 API를 사용하여 항목을 추가하고 캐시에서 항목을 가져올 수 있으며 필요한 방식으로 캐시에서 다양한 작업을 수행할 수 있습니다. 그래서, 무엇 NCache 기본적으로 다음과 같은 기능 호스트가 있습니까? NCache. 이미지가 될 수도 있고 사용자 정의 개체, 도메인 개체가 될 수도 있고 컬렉션이 될 수도 있습니다. 기본적으로 무엇이든 됩니다. 따라서 .NET에서 허용되는 모든 것은 다음 내에서 캐시될 수 있습니다. NCache 및 NCache 사용이 매우 간편하고 사용이 매우 쉬운 API는 실제로 캐시에서 다양한 작업을 수행하고 실제로 항목을 추가하고 가져올 수 있습니다.
ASP.NET, ASP.NET Core 캐싱
다음 사용 사례는 ASP.NET, ASP에 관한 것입니다..NET Core 캐싱. 따라서 첫 번째는 다음을 사용할 수 있다는 것입니다. NCache 세션 상태 공급자로. 단일 사이트 또는 다중 사이트가 될 수 있습니다. 다음은 가질 수 있다는 것입니다. NCache 보기 상태를 저장합니다. 이것은 MVC 이전의 것입니다. 그 후 뷰 상태의 개념은 더 이상 존재하지 않았습니다. 그런 다음 ASP.NET용으로 출력 캐시 공급자가 있습니다. NCache 그런 다음 ASP에 대해 작동할 수 있습니다..NET Core 핵심 응답 캐싱이 될 수 있습니다. 그래서, 당신은 그것을 할 수 있습니다 NCache. NCache 역할을 할 수도 있습니다 SignalR Backplane. 따라서 2번에서 방금 다룬 이러한 모든 옵션은 실제로 코드 변경 옵션이 아닙니다. 어떤 종류의 코드도 변경할 필요가 없습니다. 기본적으로 애플리케이션 구성 파일을 업데이트하고 실제로 보유할 수 있는 파일을 사용할 수 있습니다. NCache 저장하고 싶은 것을 저장합니다. 세션, 보기 상태, 출력 또는 핵심 응답 캐싱이 될 수 있습니다. 따라서 이것을 사용하면 다음을 수행할 수 있습니다. NCache 그 물건을 보관하십시오. 따라서 기본적으로 이 경우 다시 코드 변경 옵션이 없으며 사용하기 매우 쉽습니다. 몇 가지 단계가 필요합니다. 완전한 문서가 있습니다. 우리는 샘플도 가지고 있으며 해당 단계와 해당 문서, 심지어 샘플을 따르면 15분 이내에 설정할 수 있습니다. 모든 것을 설정할 수 있습니다. 우리는 실제로 그것을 테스트할 수 있고 그것이 당신을 위해 어떻게 작동하는지 볼 수 있습니다.
이벤트를 통한 Pub/Sub 및 런타임 데이터 공유
다음은 Pub / Sub 와 이벤트를 통한 런타임 데이터 공유. 따라서 기본적으로 이 경우 서버리스 앱이 있고 특정 메시지, 특정 데이터를 전달하려는 앱 간에 일종의 동기화가 있는지 확인하려고 합니다. NCache 그것을 위한 매체로 사용될 수 있습니다. 게시자가 있을 수 있고 구독자가 있을 수 있으며 일부 메시지를 게시할 수 있습니다. 등록된 가입자, 예를 들어 클라이언트가 실제로 가입자로부터 해당 데이터를 얻을 수 있습니다. NCache 그 경우.
따라서 일반적인 예는 그룹 채팅 응용 프로그램입니다. 그룹 구성원이 모두 동일한 캐시에 연결되어 있고 실제로 그룹 채팅에 있는 경우가 있습니다. 회원 중 한 명이 메시지를 게시하면 해당 그룹의 다른 모든 회원은 해당 데이터가 추가되었다는 알림을 받게 됩니다. 따라서 이것은 기본적인 예일 뿐이며 알림 및 연속 쿼리도 구동했습니다.
그래서, 이것들은 NCache 실제로 귀하와 대부분의 고객이 기본적으로 사용하는 것을 제공합니다.
NCache 아키텍처
에 대해 실제로 이야기해 보자. NCache 지금 건축. 어떻게 작동하는지 설명해 볼까요? 그래서 기본적으로 NCache 100% 피어 투 피어 아키텍처입니다. 단일 실패 지점이 없으며 마스터 슬레이브 또는 다수결 규칙 또는 유사한 개념이 내부에 없습니다. NCache. 서버는 즉석에서 추가 및 제거할 수 있습니다. 캐시는 중지할 필요가 없으며 계속해서 정상적으로 작동합니다. 서버 중 하나가 다운되는 경우에도 기본적으로 예상치 못한 시나리오에서 클러스터는 전체 클러스터가 다운되지 않습니다. 서버 간에 복구 논리를 시작하여 redis해당 데이터를 제공하거나 백업 중 하나에서 데이터를 가져오고 클라이언트 측에서 클라이언트는 실제로 클러스터 내에 존재하는 나머지 서버에 대한 연결을 장애 조치합니다.
따라서 이것을 사용하면 데이터가 실제로 손실되지 않고 클라이언트의 연결이 실제로 다른 서버로 장애 조치됩니다. 따라서 서버 중 하나가 다운되더라도 계속 요청합니다. 따라서 하나의 서버가 실행되고 있는 한 요청이 처리됩니다.
따라서 이러한 모든 변경 사항, 이러한 모든 구성 변경 사항 서버가 추가되고 예상치 못한 시나리오에 대해 즉석에서 제거되며 이 모든 것이 실제로 클러스터 전체에 전파됩니다. 따라서 이러한 모든 구성은 실제로 동적입니다. 클러스터 내에서 그리고 구성 측면에서 모든 업데이트는 클러스터 내에 있는 모든 서버에 매핑되고 클라이언트도 자동으로 이에 대해 알게 됩니다.
NCache 시스템 요구 사항
캐시 서버
그것에 대해 이야기합시다 NCache 시스템 요구 사항. 따라서 일반적으로 코어에 대해 이야기하면 많을수록 좋습니다. 그러나 일반적으로 8개 이상의 코어를 사용하는 것이 좋습니다. 그 주요 XNUMX가지는 NCache CPU, 네트워크 리소스 및 메모리를 사용합니다. CPU는 기본적으로 들어오는 요청을 처리하는 데 사용되거나 이러한 종류의 작업을 수행하도록 구성된 서버 측 코드가 있는 경우 CPU가 사용되는 이유입니다. 둘째, RAM은 저장용으로만 사용되며 데이터가 저장된 후 약간의 오버헤드가 발생하고 네트워크 리소스가 통신을 유지하는 데 사용됩니다. 예를 들어, 서버에서 서버로 통신한 다음 클라이언트에서 서버로 통신합니다. 따라서 이러한 옵션이 모두 있으며 권장되는 Windows 서버는 2012, 2016입니다. NCache is .NET framework, 그렇지 않으면 모든 Windows 환경에서 지원됩니다.
Remote Clients
측면에서 remote clients, 유일한 사전 요구 사항은 .NET 4.0 이상이며 클라이언트가 실제로 지원됩니다. 당신은 가질 수 있습니다 NCache 해당 서버에서.
설정 환경
자, 이제 우리는 다른 것들에 대해 이야기했습니다. 기본, 알다시피, NCache, 환경을 설정하는 방법에 대해 이야기해 보겠습니다. 따라서 고객이 우리 제품을 평가할 때마다, 우리가 그들에게 말하는 내용은 NCache. 첫 번째는 새 복사본을 다운로드하는 것입니다. NCache Enterprise 웹 사이트에서 두 번째로 설치하는 것입니다. NCache 당신의 환경 내에서. 나는 가지고있다 NCache 두 대의 컴퓨터에 이미 설치되어 있습니다. 그들은 실제로 원격 상자 demo1 및 demo2입니다. 그리고 일단 설치하면 이 상자에 NCache, 관리 도구를 얻습니다. NCache 라는 NCache 매니저. 이 도구를 사용하여 실제로 캐시를 만들고 구성하고 다른 작업을 수행할 수 있으며 심지어 모니터링 이 사건에 연루되어 있습니다.
다음을 통해 캐시 생성 NCache 매니저
자, 그럼 개봉을 해보자 NCache 여기 매니저. 검색하면됩니다 NCache 그리고 자동으로 올라옵니다. 그래서 열면 이런 풍경이 나옵니다. 이제 우리가 해야 할 일은 새로운 클러스터 캐시를 생성하는 것입니다. 이를 생성하려면 '클러스터형 캐시'를 마우스 오른쪽 버튼으로 클릭하고 '새 클러스터형 캐시 생성'을 클릭합니다.
그래서 여기서 내가 해야 할 일은 이름을 지정하는 것입니다. 이름을 '데모캐시'로 지정하겠습니다. 모든 캐시의 이름을 지정해야 합니다. 그것만 지키면 됩니다. 다음을 클릭하겠습니다.
다음은 에서 제공하는 XNUMX가지 토폴로지입니다. NCache 저는 'Partitioned Replica'가 모든 고객에게 가장 추천되고 가장 인기 있는 것이기 때문에 계속 선택하겠습니다. 그것은 매우 확장 가능하고 매우 안정적입니다.
이것은 파티션된 복제본의 경우 활성 파티션과 백업 파티션 간의 복제 전략입니다. 더 빠르기 때문에 비동기로 유지하겠습니다.
여기에서 이 클러스터형 캐시를 호스팅할 서버를 지정합니다. 여기에서는 demo1과 demo2를 지정하겠습니다. 이것은 내가 가지고 있는 두 개의 상자인 107과 108이고 다음을 클릭합니다.
클러스터가 통신하는 클러스터 포트입니다. 자동으로 픽업됩니다.
이것은 각 상자에 구성된 크기입니다. 따라서 server2에 하나, server1에 하나, 총 2Gig의 크기가 있을 것입니다.
다음은 몇 가지 고급 옵션입니다. 캐시가 가득 찬 시나리오가 있는 경우 캐시가 캐시에서 항목을 자동으로 제거할 수 있습니다. 민감한 데이터인 경우 실제로 제거를 해제하여 항목이 자체적으로 제거되지 않도록 할 수 있으며 시스템이 시작되자마자 캐시가 시작되자마자 자동으로 시작하는 옵션도 있습니다. 그래서 마침을 클릭하면 실제로 캐시가 생성됩니다.
그래서 캐시를 만드는 것이 얼마나 쉬웠는지 알 수 있습니다. 이제 캐시를 구성했습니다. 캐시 이름을 마우스 왼쪽 버튼으로 클릭하기만 하면 여기에서 필요한 모든 변경 또는 구성을 추가로 수행할 수 있는 다른 모든 탭이 열립니다.
그래서 다음으로 할 일은 내 개인 상자를 remote client. 그렇게 하려면 캐시 이름을 마우스 오른쪽 버튼으로 클릭하고 노드 추가를 클릭합니다.
그리고 여기에서는 내 개인 상자의 IP, 즉 102를 제공하고 이제 추가됩니다.
따라서 일단 추가되면 캐시 이름을 마우스 오른쪽 버튼으로 클릭하고 시작을 클릭합니다. 따라서 이제 캐시가 107 및 108 상자에서 시작됩니다. 일단 실행되면 통계를 공개하고 모니터링 도구도 보여 드리겠습니다. NCache 라는 NCache 기본적으로 캐시 내에서 진행되는 다양한 작업을 확인하는 것과 관련하여 매우 심층적인 세부 정보를 제공하는 모니터입니다. 이제 캐시가 실행 중입니다. 통계를 열려면 캐시 이름을 마우스 오른쪽 버튼으로 클릭하고 통계를 클릭하십시오.
이것이 바로 이 두 상자 107과 108에 대한 모든 통계를 불러올 것입니다.
그럼 이제 본격적으로 개봉해볼까요? 모니터링 도구 NCache. 이를 열려면 캐시 이름을 마우스 오른쪽 버튼으로 클릭하고 모니터 클러스터를 클릭하십시오.
XNUMXD덴탈의 NCache 이제 서버 대시보드와 보고서 보기 대시보드라는 두 개의 사전 구성된 대시보드를 제공하는 모니터가 열릴 것입니다. 따라서 이것을 사용하면 캐시 내에서 무슨 일이 일어나고 있는지 꽤 잘 알 수 있습니다. 바로 여기에서 볼 수 있는 것은 예를 들어 현재 사용 중인 캐시 크기이고 이것이 초당 요청 그래프입니다. 따라서 현재 캐시 내에서 진행 중인 다양한 세부 정보를 제공하며 이러한 세부 정보를 사용하여 실제로 일부 시나리오를 디버그하거나 어떤 종류의 문제가 발생하는지 확인할 수 있습니다.
그래서 그냥 빨리 돌아가서 NCache 관리자 및 여기에서 실제로 사용자 정의 대시보드를 만들 수도 있습니다. 여기에 미리 구성된 항목이 아니라 보고 싶은 특정 항목이 있는 경우 실제로 그렇게 할 수도 있습니다. 여기에 캐시 서버 범주 아래에 컨트롤이 있고 캐시 클라이언트 범주에도 컨트롤이 있습니다. 사용자 정의 대시보드를 만들어 실제로 관심이 있는 항목만 볼 수도 있습니다. NCache 관리자. 이 캐시에 대해 실행 중인 응용 프로그램이 없기 때문에 모든 것이 XNUMX으로 표시됩니다.
스트레스 시뮬레이션 및 캐시 통계 모니터링
따라서 실제로 응용 프로그램을 실행하여 빠르게 테스트해 보겠습니다. 여기에서 PowerShell을 열었습니다. 실제로 정리해보자. 실제로 새로운 것을 열어 봅시다. 자, PowerShell이 열렸습니다. 그래서 제가 할 일은 스트레스 도구 응용 프로그램을 실행하여 클러스터된 캐시에 더미 로드를 추가하고 일부 활동을 시뮬레이션하는 것입니다. 따라서 해당 활동을 사용하여 NCache 관리자뿐만 아니라 NCache 모니터, 그것이 우리에게 어떻게 작동하는지보십시오.
따라서 스트레스 테스트 도구를 실행하십시오. 다시 입력해야 합니다. 먼저 프로세스를 죽이자. 그 동안 궁금한 사항이 있으면 질문 및 답변 탭에 자유롭게 게시해 주시기 바랍니다. Kal, 현재로서는 질문이 없는 것 같습니다. 좋아, 완벽해. 선택하지 않는 이유가 있습니다. 내가 돌아왔어. 죄송합니다. 이 세션이 녹화 중이라고 말씀드리고 싶었습니다. 따라서 전체 세션에 참석할 수 없거나 초기 부분을 놓친 경우 이유가 무엇이든 이 녹음을 확인할 수 있습니다. 빠르면 다음주나 다음주 초에 올릴 예정이라고 합니다. 따라서 전체 세션을 다시 진행할 수 있습니다.
그래서, 제가 지금 하고 있는 일은 실제로 그 디렉토리로 직접 이동하여 그곳에서 명령 프롬프트를 열고 스트레스 테스트 도구를 실행하는 것입니다. 자, 이제 확인했습니다. 이제 이름을 stresstesttool.exe로 지정한 다음 데모 캐시를 지정하겠습니다. 그래서 이제 할 일은 캐시에 더미 데이터를 추가하는 것입니다. 우리가 여기로 돌아오면 지금 당장 이 두 상자에서 어떤 활동이 일어나는 것을 볼 수 있을 것입니다. 거기는. 따라서 이 상자 107과 108 모두에서 일부 활동이 발생하는 것을 볼 수 있습니다.
우리가 선택한 토폴로지에서 분할된 복제본, 각 클라이언트는 클러스터 내에 있는 모든 서버 노드에 연결되어 있기 때문에 두 서버에 모두 연결됩니다. 우리가 오면 NCache 모니터를 보면 하나의 클라이언트가 108에 연결되고 다른 하나가 107에 연결되어 있음을 알 수 있습니다. NCache 초당 요청 그래프를 보면 어떤 활동이 진행되고 있음을 알 수 있습니다.
따라서 이 테스트는 모든 것이 제대로 구성되었는지, 캐시가 올바르게 구성되었는지 확인하기 위한 것입니다. 모든 것이 제대로 작동하고 테스트를 거쳤습니다. 그래서 스트레스 테스트 도구 응용 프로그램을 중지하겠습니다. 이제 다시 본론으로 돌아가자 NCache 관리자. 계속해서 이 캐시를 지워서 추가 테스트를 위해 캐시 내에 항목이 없도록 합시다. 모든 것이 0에 표시됩니다. 프레젠테이션으로 돌아갑시다. 이제 환경이 설정되었으며 모든 준비가 완료되었습니다. 지금 우리가 할 수 있는 것은 슬라이드를 진행할 수 있다는 것입니다.
NCache 트릭 – 성능 최적화
이제 성능을 최적화하기 위해 사용할 XNUMX가지 방법에 대해 하나씩 이야기해 보겠습니다. 반복해서 말씀드리면 NCache, 클러스터 캐시는 이미 성능이 애플리케이션 내에서 성능을 향상시키고 데이터베이스 이동을 줄인 다음 메모리 내 분산 캐시인 더 빠른 소스에서 데이터를 찾는 성능 기능입니다. 그러나 이러한 기능은 실제로 특정 사용 사례에 따라 해당 성능을 향상시키는 데 도움이 될 것입니다.
- 클라이언트 캐시
그래서, 우리가 이야기 할 첫 번째 것은 클라이언트 캐시. 그것이 하는 일은 기본적으로 실제 클러스터된 캐시로의 이동을 줄이는 것입니다.
- 대량 통화
그런 다음 단일 작업만 수행하고 단일 호출만 사용하면 여러 작업이 서버 측에서 처리되는 방식으로 캐시로의 이동을 줄이는 대량 호출에 대해 설명합니다.
- 압축
그런 다음 또한 압축. 개체 크기가 더 큰 경우 이를 사용하여 추가되거나 가져오는 개체의 전체 크기를 줄일 수 있습니다. 일반적으로 개체를 더 작은 크기로 나누는 것을 권장하지만 이것이 불가능한 경우 압축 기능을 사용할 수 있습니다.
- 비동기 업데이트
또한 비동기 업데이트가 있습니다. 따라서 이를 사용하면 기본적으로 애플리케이션은 작업이 수행될 때까지 기다리지 않습니다. 이를 위해 별도의 작업을 생성한 다음 이를 기반으로 데이터가 자체적으로 추가되는 것을 감당할 수 있으며, 되돌리고 싶은 업데이트가 있는 경우 데이터가 추가되었거나 추가되지 않았거나 콜백을 등록할 수 있는 문제였습니다.
- 컴팩트 직렬화
다음은 컴팩트 직렬화. 따라서 예를 들어 직렬화 가능으로 표시되지 않고 분산 캐시 내에 사용자 지정 개체, 도메인 개체가 있는 경우 프로세스가 완전히 종료되므로 모든 개체를 직렬화해야 합니다. 따라서 환경 내에서 코드 변경을 감당할 수 없지만 사용자 지정 개체 또는 도메인 개체를 직렬화할 수 있어야 하는 이 시나리오가 있는 경우 다음의 압축 직렬화 기능을 사용할 수 있습니다. NCache 모든 것을 직렬화 가능으로 표시한 다음 실제로 계속 사용할 수 있습니다. NCache 당신의 환경 내에서. 코드 변경 없음 옵션입니다. GUI에서 파악할 수 있는 것만으로도 모든 것이 설정됩니다.
- 이중 NIC
그리고 마침내 우리는 이중 NIC 특징. 따라서 기본적으로 클라이언트에서 서버로의 통신 및 서버에서 서버로의 통신을 분리하고 네트워크 리소스를 분리하려면 실제로 다음을 사용하여 수행할 수 있습니다. NCache. 이것은 들어오는 초과 트래픽으로 인해 네트워크 리소스가 실제로 질식된 경우에만 해당됩니다. 이러한 시나리오에서만 권장합니다. 그러나 해당 시점에서 해당 리소스가 최대로 사용되지 않는 경우 실제로 두 종류의 통신에 대해 동일한 네트워크 인터페이스 카드를 유지할 수 있습니다.
Rescale과 함께 비즈니스를 가속화하는 방법에 대해 알아보세요.
따라서 캐시에 항목을 추가하고 캐시에서 항목을 가져오는 첫 번째 테스트를 실제로 수행해 보겠습니다. 이를 기본 API의 기준으로 사용할 것입니다. 다시 말하지만, 이미 최적화되어 있지만 기준으로 사용하고 그 위에 다른 기능을 수행하고 어떻게 작동하는지 확인할 것입니다.
자, 첫 번째 것, 실제로 바로 여기 이 샘플로 돌아가 보겠습니다. 따라서 이것은 실제로 이 코드도 제공할 수 있는 샘플입니다. 이것이 우리가 다룰 기준선을 보여주기 위해 사용할 것입니다. 그래서, 우리는 테스트 1에 있습니다. 테스트 1에서 우리는 기본적으로 5,000개 항목을 100KB 크기의 캐시에 추가한 다음 캐시에서 해당 항목을 가져올 것입니다. 이 테스트는 이 전체 코드에 소요되는 시간을 알려줄 것입니다. 이 가져오기 부분에는 시간이 걸릴 것입니다. 이 가져오기 부분에서 루프는 실제로 5000번 실행됩니다. 왜냐하면 5000개 항목을 가져와야 하고 이후 슬라이드에서 다양한 기능이 이 경우에 실제로 도움이 될 수 있는 방법을 다룰 것이기 때문입니다.
...
try
{
cache = NCache.InitializeCache(args[0]);
cache.Clear();
Console.WriteLine("TEST 1\n");
Console.WriteLine("Press anything to add " + objectsCount + " items (100kb Object)");
Console.ReadKey();
Console.WriteLine("Adding items now");
for (int i = 0; i < objectsCount; i++)
{
cache.Insert(key + i, obj1);
}
Console.WriteLine(objectsCount + " items added. Press any key to retrieve them.");
Console.ReadKey();
Console.WriteLine("\nRetrieving " + objectsCount + " items now");
datetime1 = DateTime.Now;
...그럼 실제로 실행해 보겠습니다. 먼저 모든 것이 올바르게 설정되었는지 확인합시다. 예, democache 테스트 1을 실행하겠습니다. 그래서, 이것은 숫자가 어떻게 생겼는지에 대한 기준선을 얻기 위한 첫 번째 테스트입니다. Enter를 누르겠습니다. 캐시에 항목을 추가하기 시작합니다. 우리가 다시 돌아온다면 NCache 관리자, 여기 있습니다. 우리는 어떤 활동이 진행되고 있음을 알 수 있습니다. 따라서 캐시에 항목을 추가하고 있습니다. 복제 토폴로지의 파티션에는 두 대의 서버가 있으므로 이 두 서버에 데이터가 추가되고 서버 1인 107에 추가되고 서버 2에도 추가됩니다. 따라서 데이터가 분할될 것입니다. 캐시 내의 모든 총 항목은 5,000개가 됩니다.
따라서 이 경우 실제로 완료될 때까지 기다렸다가 완료되면 실제로 해당 숫자를 기록해 두고 테스트할 이후 기능에 대한 비교에 사용할 수 있습니다. 거의 완료되었습니다. 약 4,000개 이상의 항목이 이미 추가되었습니다.
테스트용으로 꽤 큰 100KB 개체라는 점을 염두에 두십시오. 하지만 이것은 단지 다른 것들이 어떻게 보이는지 보여주기 위한 것입니다. 나는 그것들이 모두 추가되었다고 생각합니다. 네, 모두 추가되었습니다. 카운터는 실제로 멈췄습니다. Enter를 클릭하면 시간이 걸리고 Enter를 클릭하면 캐시에서 이러한 항목을 검색하기 시작하고 여기로 돌아오면 시간이 표시됩니다. 따라서 초당 가져오기가 실제로 증가하고 있으며 이 두 서버 모두에 대해 초당 요청도 증가하고 있음을 알 수 있습니다. 따라서 실제로 캐시에서 해당 항목을 가져오기 시작하는 약간의 활동이 있음을 보여줍니다. 캐시에서 5000개 항목을 모두 가져오면 화면에 타이머가 표시되고 해당 타이머를 사용하여 다가오는 테스트의 기준선으로 설정할 것입니다.
클라이언트 캐시(캐시 근처)
그럼 실제로 다음 이야기를 해보자. 다음 기능인 첫 번째 기능은 클라이언트 캐시입니다. 클라이언트 캐시가 무엇인지 설명하겠습니다. 클라이언트 캐시는 기본적으로 클라이언트 상자와 이러한 클라이언트 상자에 있는 로컬 캐시입니다. 이 캐시가 하는 일은 클러스터된 캐시로의 이동을 줄이는 것입니다. 클라이언트 캐시는 클러스터링된 캐시 데이터의 하위 집합입니다. 클러스터된 캐시 데이터 자체와 함께 로컬 복사본을 유지합니다. 클러스터 캐시와 동기화된 상태로 유지됩니다.
따라서 클라이언트 캐시에서 수행된 모든 업데이트는 클러스터된 캐시로 전파되며 그 반대의 경우도 마찬가지입니다. 따라서 클러스터된 캐시로 업데이트된 상태로 유지되며 애플리케이션이 캐시에서 일부 항목을 가져오려고 하는 경우 제공합니다. 해당 항목이 바로 여기에 로컬로 존재하는 경우 해당 데이터 또는 해당 항목을 바로 공유합니다. 그런 다음 로컬 소스에서.
실제로 이것으로 돌아가 봅시다. 좋습니다. 이 작업을 수행하는 데 약 45초가 걸렸습니다. 따라서 클라이언트 캐시를 사용하면 해당 시나리오 내에서 실제로 어떤 영향을 미치는지 확인할 수 있습니다. Enter를 클릭하겠습니다. 우리는 이것을 기억할 것입니다. 이 숫자는 45초입니다.
그래서 우리는 이미 클라이언트 캐시에 대해 이야기하고 있었습니다. 따라서 앞서 언급했듯이 기본적으로 두 가지 옵션이 있습니다. 클라이언트 캐시를 InProc 또는 OutProc로 실행할 수 있습니다. OutProc의 경우 클러스터된 캐시와 동기화된 상태로 남아 있는 별도의 프로세스가 실행됩니다.
OutProc 프로세스는 일반적으로 동일한 상자에서 여러 애플리케이션 또는 애플리케이션의 여러 인스턴스가 실행되는 웹 가든 시나리오가 있는 경우 권장됩니다. 따라서 그들은 처리할 공통 리소스, 즉 실행 중인 별도의 프로세스인 클라이언트 캐시를 갖게 됩니다. 두 번째 옵션은 InProc 캐시이며 일반적으로 동일한 상자에서 하나 또는 두 개의 응용 프로그램이 실행되는 웹 팜 시나리오가 있는 경우에 권장됩니다.
하나의 경우 클라이언트 캐시가 응용 프로그램 프로세스 내에 상주하기 때문에 이러한 일이 발생합니다. 따라서 이 경우 동일한 프로세스의 일부이므로 많은 오버헤드가 실제로 제거됩니다. 이 경우 직렬화 오버헤드, 프로세스 간 통신 오버헤드, 이 모두가 실제로 제거되어 성능이 크게 향상됩니다.
OutProc의 경우 캐싱하는 것은 응용 프로그램이 동일한 상자에 있는 로컬 소스에서 해당 데이터를 가져오는 것입니다. 따라서 네트워크 트립이 실제로 줄어듭니다. 따라서 성능이 상당히 향상되고 지금 바로 확인할 수 있습니다.
그래서, 여기에서 우리가 할 일은 클라이언트 캐시를 만드는 것입니다. 먼저 OutProc로, 다음으로 InProc로, 그리고 숫자 숫자가 어떻게 생겼는지 볼 것입니다. 그리고 현재 시나리오에서 일반 가져오기로 45초가 걸렸다는 것을 기억한다면.
Kal, 여기에 질문이 있습니다. 그리고 질문은 우리가 말하는 모든 기능이 동일한 제품의 일부라는 것입니다. 그래서 나는 그들이 에디션에 대해 이야기하고 있다고 생각합니다.
예, 그 중 일부는 기업에서만 사용할 수 있지만 공유할 수 있습니다. 에디션 비교 실제로 그들 각각에 대한 모든 세부 사항을 다루는 문서. 따라서 실제로 찾고 있는 정확한 세부 정보를 얻을 수 있습니다.
그리고, 이 기회를 빌어 다른 모든 사람들에게 지금 질문이 있습니까? 아니요, 질문이 없습니다. 계속해서 이야기해 주세요.
Out-Proc 클라이언트 캐시
따라서 캐시의 내용을 지우겠습니다. 이제 끝났습니다. 이제 클라이언트 캐시를 생성하겠습니다. 그래서, NCache 관리자, 여기에 작성된 클라이언트 캐시가 있습니다. 여기를 마우스 오른쪽 버튼으로 클릭하고 새 클라이언트 캐시 만들기를 클릭하십시오. 따라서 여기서는 이름을 그대로 유지하겠습니다. 클라이언트 캐시로 설정됩니다. 모든 것을 기본값으로 유지하십시오. 다음으로 지금은 OutProc로 설정되어 있지만 나중에 InProc로 변경하겠습니다. 다음을 클릭합니다. 하나의 Gig로 설정한 크기입니다. 나는 그것을 유지할 것입니다. 실제로 클러스터 캐시를 생성할 때 존재했던 추가 고급 설정과 원하는 것으로 변경할 수 있습니다. 이제 클라이언트 캐시는 실제로 내 개인 상자, 즉 102에 구성됩니다.
이를 확인하는 빠른 방법은 설치 후 내 개인 상자에 있는 목록 캐시 도구를 실행하는 것입니다. NCache 이 도구를 사용하면 실제로 NCache이 시점에서 내 개인 상자에서 실행 중입니다. 자, 여기까지 오면 실제로 목록 캐시를 실행해 보겠습니다. 좋아, 그것은 내 개인 상자에 있는 캐시, 즉 102를 표시하고 있습니다. 제 생각에는 뒤에서 어떤 이유에서인지 여전히 활성화하려고 시도하고 있다고 생각합니다. 예, 거기에서 활성화 된 것 같습니다. 따라서 여기에 오면 클라이언트 캐시를 볼 수 있습니다. 따라서 클라이언트 캐시는 바로 여기에서 로컬 캐시이며 실행 중입니다. 그래서 지금은 내 개인 상자에서 실행 중이며 이제 실제로 사용할 수 있습니다.
그래서 실제로 진행하기 전에 NCache 그것은 바로 지금 화면에 표시되는 이러한 카운터를 게시한다는 것입니다. 따라서 Windows 성능 모니터를 통해 볼 수 있습니다. 내가 할 일은 Windows 성능 모니터를 열고 내가 사용할 클라이언트 캐시에 대한 카운터를 여는 것입니다.
그래서 저는 제 개인 상자에서 바로 여기에서 성능 모니터링인 PerfMon을 검색할 것입니다. 그리고 이것을 사용하여 제가 할 일은, NCache 범주에서 클라이언트 캐시였던 특정 캐시를 찾아 카운터를 엽니다. 이제 열렸고 새로운 성능 모니터를 열어 다음 범주를 찾습니다. NCache. 여기 있고 여기에 클라이언트 캐시가 있습니다. 추가를 클릭하고 확인을 클릭하겠습니다. 보기를 보고서 보기로 변경하겠습니다. 자, 이제 이것들이 카운터입니다. 현재 사용되지 않기 때문에 모든 것이 0으로 표시됩니다. OutProc로 설정했기 때문에 실행되는 별도의 프로세스입니다.
이제 내 개인 상자에서 숫자가 어떻게 보이는지 봅시다. 동일한 코드로 응용 프로그램을 실행할 것입니다. 어떤 종류의 코드 변경도 수행하지 않습니다. 클라이언트 캐시 기능은 코드 변경이 없습니다. 앞서 언급했듯이 원하는 대로 활성화하거나 비활성화하면 자동으로 선택됩니다. 따라서 시작 버튼, 동일한 코드, 동일한 모든 것, 동일한 테스트를 클릭하면 'Enter'를 클릭하면 해당 항목이 추가되기 시작합니다. 좋습니다. 엔터를 클릭하면 이러한 항목이 추가되기 시작했습니다. 로 돌아간다면 NCache 관리자를 보면 클러스터 캐시에 항목이 추가되고 있음을 알 수 있습니다. 개봉하면 NCache 모니터, 이것이 바로 이것입니다. 예, 이것입니다. 여기에서도 약간의 활동이 진행되고 있다는 것을 알 수 있습니다. 이것이 제가 처음에 설명했던 것입니다. 클라이언트 캐시를 구성한 경우 캐시에 항목을 추가하면 클라이언트 캐시도 복사본을 가져오고 클러스터형 캐시도 복사본을 가져옵니다.
이 사용 사례는 일반적으로 읽기 대 쓰기 비율이 80%~20%이거나 읽기 대 쓰기 비율이 70%~30%인 경우에 권장됩니다. 이것은 일반적으로 읽기가 많은 시나리오에서 권장되며, 아마도 환경 내에 있는 정적 데이터의 일부 참조 데이터일 수 있으며 클라이언트 캐시를 사용하도록 설정하면 성능이 크게 향상됩니다.
따라서 루프에서 실행되는 get API만 사용한 첫 번째 테스트에서는 캐시에서 해당 항목을 가져올 수 있는 데 45초가 걸렸습니다. 그러나 이제 이 클라이언트 캐시를 사용하면 동일한 상자에서 실행되는 별도의 프로세스에서 로컬 소스 내의 모든 데이터를 찾을 수 있으며 이것이 어떻게 작동하는지 살펴보겠습니다. 따라서 여기에서 아래로 스크롤하면 이것이 클라이언트 캐시의 수임을 알 수 있습니다. 이 수는 단일 소스이기 때문에 최대 5,000개까지 올라갑니다. 따라서 모든 5,000개 항목이 클러스터에 표시되고 모든 서버 노드에 배포됩니다. 따라서 우리는 이러한 항목이 최대 5,000개까지 오를 때까지 기다렸다가 클러스터된 캐시에서 이러한 항목을 가져오는 테스트의 두 번째 부분을 실행할 것입니다.
따라서 주목해야 할 또 다른 사항은 캐시에서 항목을 가져오면 호출이 클러스터된 캐시로 이동하지 않고 현재 로컬에 있는 클라이언트 캐시에 의해 모두 가로채어집니다. 여기 카운터에서 온 당신. 따라서 이러한 카운터는 클라이언트 캐시 카운터를 표시하지만 여기에 올 경우 클러스터된 캐시에 대한 서버 측 카운터가 표시됩니다. 여기에서 입력을 클릭하면 캐시에서 이러한 항목을 검색하기 시작합니다. 여기에서 카드가 이동되지 않음을 다시 한 번 보여 드리겠습니다. 그래서 여기로 전화가 오지 않습니다. 이것을 열면 이 활동이 여기에서 진행되고 있음을 알 수 있습니다. 특정 가져오기가 진행 중입니다. 따라서 클라이언트 캐시는 현재 많이 사용되고 있으며 쓰기보다 읽기가 더 많은 시나리오에서 클라이언트 캐시를 사용하는 요점입니다. 따라서 몇 초 후에 클라이언트 캐시 시나리오에서 크기가 5,000KB인 항목 100개를 표시하는 데 걸린 시간에 대한 결과를 볼 수 있습니다. 따라서 여기에서 환경 내에서 OutProc 클라이언트 캐시가 활성화된 경우 45초에서 33초로 줄어든 것을 볼 수 있습니다.
따라서 크게 개선되었음을 알 수 있습니다. 10초 이상을 볼 수 있고, 어플리케이션 면에서는 큰 시간입니다. 따라서 이 경우에 우리에게 큰 개선을 보여주었습니다.
In-Proc 클라이언트 캐시
이제 In-Proc 클라이언트 캐시를 만들고 해당 InProc 클라이언트 캐시를 사용하여 실제 테스트의 경우 45초, 클라이언트 캐시 OutProc 테스트. 우선 이 캐시를 제거하겠습니다. 이제 제거되었습니다. 새로운 캐시를 생성하겠습니다. 다시 말하지만, 그 옆에 InProc를 입력하고 다음을 클릭하고 격리 수준을 InProc로 유지하고 모든 것을 기본값으로 유지하고 마침을 클릭하겠습니다. 이제 이것은 내 개인 상자에 생성되었으며 정확히 동일한 테스트를 실행할 것입니다. 사실 먼저 캐시의 데이터를 지우자.
이제 동일한 테스트, 동일한 주장, 그리고 방금 시작했습니다. 이제 똑같은 테스트를 다시 수행할 것입니다. 5000개 항목을 100KB 크기의 캐시에 넣은 다음 클라이언트 InProc 클라이언트 캐시를 사용하여 해당 항목을 가져옵니다. 개념은 정확히 동일하게 유지됩니다. 애플리케이션이 캐시에 항목을 추가하면 동일한 프로세스에 있는 클라이언트 캐시에도 추가할 수 있습니다. 지금은 In Proc로 실행하고 있기 때문입니다. 따라서 해당 항목을 클라이언트 캐시에도 추가하고 클러스터형 캐시에도 추가합니다. 이제 입력을 클릭하겠습니다. 따라서 해당 항목을 가져오면 동일한 프로세스 내에서 로컬 내의 모든 항목을 찾을 것입니다.
따라서 이제 프로세스 간 통신 및 직렬화, 역직렬화와 같은 오버헤드와 관련된 모든 것이 이제 완전히 제거됩니다. 바로 그곳에서 데이터를 가져온 다음 로컬 소스에서 데이터를 가져오고 이 특정 시나리오에 대해 InProc 모드에서 클라이언트 캐시가 실제로 얼마나 크게 수행되는지 확인할 수 있습니다. 따라서 항목이 추가되기를 기다리면 됩니다. 여기로 돌아오면 카운터가 위아래로 움직이는 것을 볼 수 있습니다. 우리는 그것을 확실히 볼 수 있습니다.
그럼, 그동안 질문이 있으면 알려주세요. Sam은 질문 창 탭을 주시하고 있습니다. 그는 질문이 있으면 나에게 알려줄 것이다.
따라서 목록에서 앞서 언급한 다음 작업은 대량 작업이 될 것입니다. 따라서 대량 API를 사용하는 단일 항목으로만 테스트할 것입니다. 그러나 대량 작업과 매우 동일한 방식으로 수행되는 여러 가지 개념이 있으며 이 프레젠테이션에서는 이 모든 것을 이론상으로 다룹니다. 실제로 얼마나 많은 항목이 추가되었는지 봅시다. 따라서 약 3000개 이상의 항목이 이미 추가되었습니다. 따라서 우리는 완전한 5000 마커가 도달하기를 기다리고 있으며 그 후에 이것이 어떻게 작동하는지 볼 것입니다. 좋아, 첫 번째와 붙어있다. 그래서, 나는 뒤에서 수행되는 수술을 기다리고 있습니다. 그동안 대량 작업의 경우 여기에서 가장 먼저 언급한 사항에 대해 말씀드리겠습니다.
따라서 대량 작업의 핵심 개념은 클러스터된 캐시로 들어가는 실제 호출 양을 제한하는 것입니다. 따라서 루프 내에서 모든 작업을 수행하는 대신 이미 한 것처럼 실제로 단일 작업의 일부로 동일한 호출을 수행할 수 있습니다. 따라서 클러스터된 캐시로 단일 작업을 보낸 다음 이에 대해 여러 작업을 수행할 수 있습니다. 따라서 대량의 경우 공유하는 경우 키를 알아야 합니다. 따라서 예를 들어 추가하려는 키와 실제 개체를 제공한 경우 한 번만 호출하면 모든 항목이 실제로 뒤쪽의 클러스터형 캐시에 추가됩니다.
그래서, 그것들이 완료되어야 한다고 생각합니다. 예, 이제 거의 완료되었습니다. 여기로 돌아오면 이제 이 모든 항목이 추가됩니다. Enter를 클릭하면 해당 항목이 모두 검색된 것을 볼 수 있습니다. 이제 많은 오버헤드가 제거되었기 때문에 매우 놀랍습니다. 그래서 굉장히 빨랐습니다. 따라서 초기 테스트를 반복하면 기본 테스트에서는 45초가 걸렸고 클라이언트 캐시 OutProc에서는 약 33초가 걸렸습니다. 하지만 InProc 클라이언트 캐시의 경우 이 모든 시간이 0.1초로 줄어들었습니다.
따라서 사용 사례가 바로 여기에서 진행 중인 것과 일치하는 경우 InProc 클라이언트 캐시에서 볼 수 있는 개선 사항입니다. 따라서 더 많은 읽기 및 쓰기가 진행 중인지 확인할 수 있는 훌륭한 개선 사항입니다.
그래서 저는 그냥 엔터를 눌러보겠습니다. 그래서, 그것은 가까워집니다. 여기에서 이 클라이언트 캐시를 제거하고 실제로도 정리하겠습니다. 자, 이제 프레젠테이션으로 돌아갑시다. 그래서, 여기에서, 우리는 대량 작업에 대해 이야기하고 있었습니다.
대량 가져오기(키 기반)
따라서 대량 작업의 경우 첫 번째는 추가할 때 캐시에서 추가하거나 가져오고 싶은 항목이 많으면 그에 따라 목록을 제공하고 단일 호출을 사용하여 캐시에서 이러한 모든 작업을 수행할 수 있습니다. 따라서 일반적으로 개체 크기가 더 큰 경우 여러 개체로 나눈 다음 다음 기능을 사용하는 것이 좋습니다. NCache 실제로 그룹화하거나 가져오거나 캐시에 추가할 수 있습니다. 따라서 이러한 시나리오에서 대량 API를 사용할 수 있습니다. 두 번째는 예를 들어 이러한 항목의 키를 모르는 경우 대량은 키 기반 작업이므로 모든 키를 알아야 합니다.
SQL/LINQ 검색 쿼리
SQL이나 LINQ 형식의 검색 쿼리에서는 기본적으로 키를 모르면 실제로 특정 기준으로 검색할 수 있습니다. 예를 들어 캐시에 제품이 추가된 경우 특정 기준에 따라 캐시에서 실제로 여러 제품을 가져올 수 있습니다. 이름으로 쿼리를 실행한다고 가정해 보겠습니다. '제품 선택 WHERE product.price > 10 AND product.price < 100'. 따라서 실제로 특정 기준을 충족하고 캐시에 있는 모든 제품은 실제로 나에게 반환됩니다. 따라서 이 경우에는 키를 지정하지 않고 기준만 지정하여 반환했습니다.
그룹 및 하위 그룹
다음은 캐시 내에서 논리적 컬렉션을 생성할 수 있는지 여부입니다. 나는 그룹, 하위 그룹 및 태그로 두 가지를 함께 다룰 것입니다. 그래서, 당신은 할 수 있습니다. 따라서 예를 들어 고객과 고객의 주문이 캐시 내에 있는 경우 실제로 모든 주문을 함께 그룹화할 수 있습니다. 캐시에 별도의 항목이 있으므로 실제로 컬렉션도 유지할 수 있지만 일반적으로 캐시에서 항목을 가져오면 전체 개체가 필요하지 않기 때문에 컬렉션을 분할하는 것이 좋습니다. 따라서 여러 개체로 나누면 더 효율적인 방식으로 사용할 수 있습니다. 따라서 이러한 논리적 수집 기능을 사용하여 기본적으로 캐시 내의 항목을 그룹화할 수 있습니다. 따라서 특정 고객의 모든 주문을 단일 통화로 그룹화할 수 있습니다. 그룹에서 get by group을 수행하거나 태그의 경우 get by tag를 수행할 수 있으며, 고객 ID만 제공하면 캐시 내에 있는 이러한 모든 관련 항목이 실제로 반환됩니다. 다시 말하지만, 이 경우 키를 알 필요가 없습니다. 그룹 또는 태그인 특정 문자열 값만 알면 됩니다. 이를 기반으로 반환된 다음 병렬 쿼리도 지원합니다.
대량 작업 - 데모
이제 실제 대량 작업 샘플을 살펴보겠습니다. 자, 이 테스트로 돌아온다면 바로 여기입니다. 이것은 대량 테스트, 즉 테스트 2이며 실제로 실행할 것입니다. 먼저 실제로 시작한 다음 수행 중인 작업에 대해 자세히 알아보겠습니다. 그래서 지금 테스트 2로 변경하고 시작했습니다. 따라서 이 테스트는 기본적으로 현재 캐시에 크기가 10,000KB인 항목 10개를 추가하는 것입니다. 첫째, 이러한 항목을 캐시에 추가하는 기본 삽입을 수행한 다음 이러한 모든 항목을 가져오고 실제로 추가 및 가져오는 부분에 대한 시간을 기록하고 있습니다.
Console.WriteLine("TEST 2\n");
Console.WriteLine("Press anything to add " + objectsCountBulk + " items (10kb Object)");
Console.ReadKey();
Console.WriteLine("Adding items now");
datetime1 = DateTime.Now;
for (int i = 0; i < objectsCountBulk; i++)
{
cache.Insert(key + i, obj2);
}
datetime2 = DateTime.Now;
Console.WriteLine(objectsCountBulk + " items added. Time to add " + objectsCountBulk + " items in a loop: " + (datetime2 - datetime1).TotalSeconds);
Console.WriteLine("\nPress any key to retrieve them.");
Console.ReadKey();따라서 일단 완료되면 크기가 10,000KB인 항목 10개를 캐시에 추가하는 데 걸린 기준선을 얻은 다음 대량 작업을 시작합니다. 이러한 대량 작업에서는 10,000개 항목을 모두 동일한 호출로 캐시에 추가하고 키 목록과 개체 목록이 미리 정의된 상태에서 단 한 번의 호출로 다시 가져옵니다.
알겠습니다. 엔터를 클릭하겠습니다. 해당 항목을 캐시에 추가하기 시작합니다. 우리가 다시 돌아온다면 NCache 관리자 우리는 여기서 약간의 활동이 진행되고 있음을 알 수 있습니다. 이러한 항목은 현재 현재 존재하는 두 서버에 모두 추가되고 있습니다.
모니터 클러스터를 보더라도 여기에 연결된 하나의 클라이언트, 거기에 연결된 하나의 클라이언트를 볼 수 있으며 이 그래프에서 약간의 활동이 진행되고 있음을 알 수 있습니다. 따라서 이것을 사용하면 실제로 캐시 내에서 무슨 일이 일어나고 있는지, 무엇을 사용하고 있는지, 이 시점에서 무엇이 사용되지 않고 있고 얼마나 많이 사용되고 있는지에 대한 꽤 좋은 아이디어를 얻을 수 있습니다. 10,000개 항목이 거의 완료되었으며 이제 추가된 것 같습니다. 그렇습니다. Enter 키를 눌러 이 10,000개 항목을 검색하겠습니다. 따라서 우선 이러한 항목을 캐시에 추가하는 데 약 37초가 걸렸습니다. 이제 캐시에서 10,000개의 항목을 읽는 것입니다. 따라서 여기에서 두 서버 노드 모두에서 초당 일부 가져오기가 수행되고 있음을 알 수 있습니다. 따라서 현재 항목을 가져오는 중입니다. 그래서 지금 루프에서 가져오고 있습니다. 일단 완료되면 대량 테스트를 시작할 것임을 염두에 두십시오. 따라서 해당 일괄 테스트를 기반으로 이 두 숫자를 비교하고 실제로 어떤 영향을 미치는지 확인할 것입니다. 그래서 여기에서 이 30개 항목을 검색하는 데 약 10,000초가 걸렸고 대량 API를 사용하면 실제로 추가가 완료되었으며 가져오기 부분도 곧 완료되어야 한다고 생각합니다. 오 예, ENTER를 눌러야 합니다. 자, 실제로 완료될 때까지 기다렸다가 이 모든 것이 어떻게 보이는지 실제로 보여드릴 수 있습니다. 이제 완료되었습니다. 따라서 이 테스트를 살펴보기 위해 루프를 사용하여 10,000KB 크기의 항목 10개를 캐시에 추가했으며 약 37초가 걸렸습니다. 이 10,000개 항목을 검색하는 데 루프에서 다시 약 30초가 걸렸습니다. 일괄 테스트에서는 10,000개 항목을 캐시에 추가했고 약 5초가 걸렸습니다.
따라서 이것은 37초와 5초 사이의 큰 간격이며 캐시에서 해당 항목을 가져오는 데 약 6초가 걸렸습니다. 그래서 다시 6초와 30초의 차이가 큽니다. 따라서 이것은 대량 작업이 실제로 사용자와 응용 프로그램에 제공할 수 있는 개선 정도이며 이를 사용하면 동일한 호출을 반복해서 실행할 필요가 없습니다. 매번 클러스터링된 캐시로 이동할 필요가 없습니다. 기본적으로 수행해야 하는 모든 작업의 모음을 만들 수 있으며 대량 API를 사용하여 캐시에 추가할 수 있습니다.
압축 - 데모
이제 대량 테스트가 실제로 완료되었습니다. 자, 프레젠테이션으로 돌아갑니다. 그래서 다음은 압축 테스트입니다. 다시 말하지만, 앞서 언급했듯이 일반적으로 개체를 더 작은 크기로 나누는 것이 좋지만 해당 옵션을 사용할 수 없는 경우 실제로 압축할 수 있고 실제로 특정 임계값을 설정할 수 있습니다. 그보다 큰 개체는 더 작은 크기로 압축되지 않습니다. 실제로 지금 우리 환경에서 압축을 활성화해 보겠습니다. 따라서 우선 캐시를 삭제해 보겠습니다. 끝났다. 압축은 즉석에서 수행할 수 있는 작업입니다. 따라서 캐시를 중지할 필요가 없습니다. 따라서 캐시 이름을 마우스 왼쪽 버튼으로 클릭하면 이러한 다양한 구성이 모두 열립니다. 여기로 가서 옵션을 열면 압축 활성화를 클릭하기만 하면 됩니다. 50KB로 설정하겠습니다. 따라서 50KB보다 큰 것은 압축됩니다. 캐시 이름을 마우스 오른쪽 버튼으로 클릭하고 구성 적용을 클릭합니다. 이제 이러한 모든 구성이 클러스터에 적용됩니다. 따라서 그보다 큰 개체는 실제로 압축됩니다.
그래서, 저는 우리가 처음에 했던 것과 똑같은 테스트를 실행할 것이고 그것이 테스트 1이었습니다. 이것을 다시 테스트 1로 변경하고 이것을 저장하고 실행(시작)을 누르겠습니다. 압축이 시작될 때까지 기다렸다가 다양한 시나리오에서 압축이 실제로 어떻게 도움이 되는지 자세히 설명하겠습니다. 따라서 압축이 작동하는 방식은 클라이언트가 이러한 항목을 캐시로 보내면 압축된 상태로 보내는 것입니다. 따라서 압축이 도움이 되는 방법은 항목이 네트워크를 통해 이동하면 크기가 더 작아지고 클러스터된 캐시에 머무르면 위치를 덜 차지한다는 것입니다.
Kal, 세션이 끝나기까지 10분 남았으니 그에 따라 속도를 조절하세요. 알겠습니다. 감사합니다. 이 시점에서 질문이 있습니까? 아니, 모두가 좋은 것 같다. 사실, 우리는 두 가지 확인을 받았고 지금까지 너무 좋았습니다. 그래서 우리는 좋습니다. 좋아, 완벽해. 고맙습니다.
자, 압축이 어떻게 도움이 되는지에 대해 이야기하고 있었습니다. 따라서 두 가지가 있는 경우 더 작은 크기의 개체의 전체 네트워크 이동은 분명히 더 큰 크기의 것보다 빠를 것이며 해당 개체가 캐시에 배치되면 Enter를 클릭하여 이러한 항목 검색을 시작합니다. . 따라서 캐시 내에 배치되면 실제로는 더 작아집니다. 따라서 공간을 덜 차지합니다. 이 항목을 처리하는 데 걸리는 전체 시간도 줄어듭니다. 이것이 바로 압축이 시나리오 내에서 도움이 되는 방식입니다. 추가하는 동안 클라이언트 측에서 오버헤드가 발생합니다. 그러나 우리가 지금 주목하게 될 전체 순 개선은 실제로 그보다 더 큽니다. 따라서 이러한 항목에 대한 전체 작업이 발견되는 데 걸리는 전체 시간은 실제로 훨씬 더 빠를 것입니다. 따라서 압축으로 수행된 테스트 1은 약 26초가 걸렸습니다.
당신이 처음에 기억한다면, 우리의 첫 번째 테스트에서 아무 것도 없었고 특별한 기능도 없이 기본 API만 포함하여 45초가 걸렸다고 생각합니다. 따라서 45초와 26초 사이에는 큰 차이가 있습니다. 따라서 압축이 실제로 도움이 되는 정도이며 이러한 작업을 훨씬 더 확장하면 이 경우 더 큰 차이가 발생합니다. 따라서 이 경우에 많은 도움이 됩니다.
비동기 작업 - 데모
이제 실제로 다음 시나리오인 비동기 업데이트로 이동해 보겠습니다. 비동기 업데이트는 기본적으로 애플리케이션이 기다리지 않는다는 것입니다. 별도의 작업을 설정할 수 있으며 해당 작업은 해당 작업을 수행합니다. 어떤 시나리오에서 항목이 추가되었거나 추가되지 않은 경우 정보를 가져오도록 콜백을 설정할 수 있습니다. 실제로 설정할 수도 있습니다. 지금은 샘플로 빨리 가려고 하는데 테스트 3번인 것 같은데 금방 확인이 가능합니다. 좋습니다. 이것은 비동기 업데이트에 대한 테스트 번호 3입니다. 실제로 시작하고 코드의 세부 사항을 살펴보겠습니다. 다시 제어할 수 있게 되면 코드 파일을 열고 실제로 비동기 업데이트에 대한 테스트 번호 3에서 무슨 일이 일어나고 있는지 보여드리겠습니다. 지금 시작했습니다. 따라서 비동기 업데이트에서 테스트 번호 3이 진행됩니다. 먼저 기본 삽입 호출을 사용하여 캐시에 항목을 추가한 다음 해당 항목 추가가 완료되면 기본적으로 일부에서 다시 제거합니다. 고리. 따라서 각 키는 단일 반복에서 제거됩니다.
...
else if (args[1].Equals("test3"))//ASYNC API TEST
{
Console.WriteLine("TEST 3\n");
Console.WriteLine("Press anything to add " + objectsCount + " items normally (100kb Object)");
Console.ReadKey();
Console.WriteLine("Adding items now");
try
{
cache = NCache.InitializeCache(args[0]);
datetime1 = DateTime.Now;
for (int i = 0; i < objectsCount; i++)
{
cache.Insert(key + i, obj1);
//cache.InsertAsync(key + i, obj1, OnItemAdded, "", "");
}
...Enter를 클릭하겠습니다. 5,000KB 크기의 캐시에 100개의 항목을 추가하고 있으며 정상적으로 수행하고 있습니다. 일반적으로 여기에서는 단순한 삽입을 의미하고 루프의 일부에서 해당 항목을 다시 제거합니다. 따라서 이것을 사용하여 이 부분에 소요되는 시간을 확인한 다음 나중에 추가, 비동기 삽입 및 제거를 위해 비동기 호출을 사용할 것입니다. 이러한 항목을 추가하는 동안 실제로 뒤로 이동하여 어떻게 보이는지 살펴보겠습니다. 따라서 이 경우 이러한 항목을 제거하기 위해 기본 제거를 수행하는 것입니다. 비동기 테스트 부분에서 수행하는 작업은 삽입 비동기 호출을 수행하는 것입니다. 따라서 클라이언트는 기다리지 않고 작업을 대기열에 전달합니다. 대기열이 느린 프로세스가 될 것이라는 의미는 아닙니다. 클라이언트는 기다리지 않고 백그라운드 프로세스로 꽤 빨리 완료되지만 꽤 빨리 완료됩니다. 캐시 내의 많은 작업이 실제로 비동기 방식으로 수행되기 때문입니다.
...
datetime2 = DateTime.Now;
Console.WriteLine("Time to remove " + objectsCount + " objects normally: " + (datetime2 - datetime1).TotalSeconds);
Console.WriteLine("\nAdding items using Async API now");
datetime1 = DateTime.Now;
for (int i = 0; i < objectsCount; i++)
{
//cache.Insert(key + i, obj1);
cache.InsertAsync(key + i, obj1, OnItemAdded, "","");
}
datetime2 = DateTime.Now;
Console.WriteLine("Time to add " + objectsCount + " objects with Async API: " + (datetime2 - datetime1).TotalSeconds);
Console.WriteLine("\nRemoving " + objectsCount + " items with Async API now");
...예를 들어보겠습니다. 예를 들어 복제에 대해 이야기하는 경우 캐시 생성 프로세스에서 기억한다면 비동기로 설정합니다. 따라서 기본적으로 많은 부분이 백그라운드 프로세스로 수행됩니다. 그들은 매우 신뢰할 수 있습니다. 당신의 애플리케이션, 메인 프로세스, 메인 작업이 영향을 받지 않는다는 것뿐입니다. 따라서 해당 항목을 캐시에 추가했는데 해당 항목을 캐시에 추가하는 데 약 49초가 걸렸습니다. 이제 실제로 5,000개 항목을 제거하고 있습니다. 이제 이것이 완료되면 비동기 호출이 어떻게 수행되는지 볼 것입니다. 따라서 5,000개의 항목을 이동해야 합니다. 해당 항목을 제거하는 데 약 25초가 걸렸고 이제 비동기 호출로 항목을 추가하고 있습니다. 우리는 49초와 다음과 관련하여 지금 얻을 수 있는 숫자 사이에 얼마나 많은 차이가 있는지 확인할 것입니다. 캐시에 항목을 다시 추가합니다. 거기는. 그래서 추가 부분에서는 49초에서 28초로, 해당 항목을 제거할 경우에는 25초에서 1.6초로 줄였습니다. 따라서 이것이 포함된 후에 실제로 볼 수 있는 성능입니다. 따라서 큰 차이가 있음을 알 수 있습니다. 기본 제거 호출에서 항목을 제거한 다음 비동기 제거 호출에서 항목을 제거하는 데 약 25초의 차이가 있습니다. 따라서 이러한 종류의 기능에서 기대할 수 있는 것은 NCache.
이중 NIC - 데모
실제로 프레젠테이션으로 돌아가 보겠습니다. 우리는 비동기를 다루었고 다음은 컴팩트 직렬화입니다. 다시 말하지만, 이것은 코드 내에서 업데이트를 수행할 여유가 없고 이를 사용하여 실제로 모든 클래스를 직렬화 가능으로 표시할 수 있는 시나리오에서 다룹니다. 칼 그 댓글과 함께 3분 남짓 남았으니...맞아, 맞아. 그냥 빨리 덮어버리겠습니다. 따라서 마지막 두 가지가 남았습니다. 하나는 컴팩트 직렬화이고 그 다음은 이중 NIC 기능이 있다는 것입니다. 따라서 앞에서 언급한 것처럼 네트워크 리소스가 최대로 사용되는 경우 기본적으로 서버 간 통신 및 클라이언트 대 서버 통신의 두 종류가 모두 동일한 네트워크 인터페이스 카드에서 발생합니다. 그러나 네트워크 리소스가 최대로 사용되는 것을 확인하면 클라이언트에서 서버로, 그리고 나서 서버에서 서버로의 통신 유형을 분리할 수 있습니다. 내부에서 매우 간단한 작업입니다. NCache 관리자. 여기로 오면 선택하려면 여기를 마우스 오른쪽 버튼으로 클릭하고 NIC 선택을 클릭하십시오.
NIC를 선택하면 이 특정 IP에서 수행할 통신을 실제로 지정할 수 있습니다. 하나밖에 없기 때문에 이러한 옵션을 사용할 수 있습니다. IP가 여러 개인 경우 실제로 바로 거기에서 선택할 수 있습니다. 그래서 그냥 취소를 눌러보겠습니다.
시간 부족으로 인해 컴팩트 직렬화 데모를 할 기회가 없었지만 실제로 이 샘플을 여러분과 공유할 수 있으며 테스트하고 이것이 어떻게 작동하는지 확인할 수 있습니다. 당신에게 샘. 완벽한. 시간 내주셔서 감사합니다. Kal.
오늘 세션을 마치기 전에 질문이 있습니까? 질문이 있는지 잠시만 살펴보겠습니다. 자, 질문이 있습니다.
이 프레젠테이션을 공유할 링크를 공유할 수 있습니까? 칼, 우리 웹사이트에서 구할 수 있을 것 같은데요?
예, 사용할 수 있을 예정이며 이메일을 메모해 두었습니다. 그래서 제가 할 수 있는 일은 업로드되는 즉시 이메일을 보낼 수 있다는 것입니다. 확인. 사실 다른 질문이 있습니다.
프리젠테이션 일정을 잡을 수 있을까요? 그럼 우리 팀을 위한 데모 일정을 잡을 수 있을까요?
네 그럼요. 당신은 확실히 데모를 예약할 수 있습니다. 지원팀에 문의할 수 있습니다. support@alachisoft.com 또는 우리의 영업 팀 sales@alachisoft.com 선호하는 시간을 알려주시면 기꺼이 맞춤 세션을 예약해 드리겠습니다.
알겠습니다. Kal 그럼 이만 마무리하겠습니다. 더 이상 질문이 없는 것 같습니다. 오늘 세션에 참여하고 참석해 주신 모든 분들께 감사드립니다. 감사합니다. 말씀드린 것처럼 질문이 있는 경우 지원팀에 문의하거나 영업 관련 질문은 영업팀에 문의하세요. 도와드리겠습니다. 언제든지 전화주세요. 전화로도 직접 연락할 수 있습니다. 저희 웹사이트에 있습니다. 다음 시간까지 정말 감사하고 좋은 저녁 되세요, 안녕.