올랜도 코드 캠프 2019
ASP 최적화.NET Core 분산 캐시의 성능
이크발 칸
사장 및 기술 전도사
ASP.NET Core 트래픽이 많은 웹 애플리케이션 개발에 빠르게 인기를 얻고 있습니다. ASP 최적화 방법 알아보기.NET Core 오픈 소스 .NET 분산 캐시를 사용하여 속도 저하 없이 극단적인 트랜잭션 로드를 처리하는 성능. 이 강연에서는 다음을 다룹니다.
- ASP 개요.NET Core 성능 병목 현상
- 분산 캐싱 개요 및 성능 문제 해결 방법
- 애플리케이션에서 분산 캐싱을 사용할 수 있는 위치
- 몇 가지 중요한 분산 캐시 기능
- 오픈 소스를 사용한 실습 예제 NCache 분산 캐시로
ASP를 최적화하는 방법에 대한 주제를 살펴보겠습니다..NET core 성능 향상을 위한 기술로 분산 캐싱을 사용할 것입니다. NCache 이것의 예로서.
ASP.NET Core 인기(트래픽이 많은 앱)
우리 모두는 ASP가.NET core 새로운 .NET core, 깨끗하고 가벼운 아키텍처, 크로스 플랫폼 및 오픈 소스 그리고 이것이 점점 더 많은 사람들이 ASP로 이동하는 주요 이유가 되고 있습니다..NET core.
또한 거대한 레거시 ASP.NET 사용자 기반이 있으며 특히 ASP.NET MVC 응용 프로그램인 경우 ASP로 이동합니다..NET core 매우 간단합니다. MVC가 아니라면 당연히 작성해야 할 코드가 많습니다. 따라서 이러한 모든 이유 때문에 귀하도 여기 있는 이유는 ASP 때문입니다..NET core 웹 애플리케이션을 수행하기 위한 최고의 .NET 선택입니다.
ASP.NET Core 확장성 필요
따라서 ASP가 있는 경우.NET core 교통량이 많은 상황에서 점점 더 많이 사용되고 있습니다. 높은 트래픽은 일반적으로 고객 대면 애플리케이션이 있음을 의미합니다. 온라인 비즈니스일 수도 있고 소매 비즈니스일 수도 있습니다. 수많은 산업, 의료, 전자 정부, 소셜 미디어, 온라인 베팅, 도박, 생각할 수 있는 모든 것이 있습니다. 요즘은 모두 온라인 상태입니다. 그래서 누구든지! 웹 어플리케이션 ASP가 있을 때.NET core ASP를 의미하는 사용 중.NET core 확장 가능해야 합니다.
확장성이란 무엇입니까?
그게 무슨 뜻이야? 당신이 그것에 대해 많이 알고 있을 것이라고 확신하지만 완전성을 위해 용어를 정의하겠습니다.
따라서 확장성은 사용자가 XNUMX명인 응용 프로그램이 있는 경우 응답 시간이 정말 좋은 경우 응용 프로그램을 클릭하고 XNUMX~XNUMX초 내에 페이지가 다시 표시되는 것을 의미합니다. 그런 다음 XNUMX, XNUMX 또는 XNUMX명의 사용자로 동일한 응답 시간을 달성할 수 있다면 응용 프로그램을 확장할 수 있습니다. 할 수 없다면 확장할 수 없습니다. XNUMX명의 사용자로 높은 성능을 발휘하지 못한다면 코드 작성 방법에 대한 다른 토론으로 이동해야 합니다. 그러나 귀하의 응용 프로그램이 좋은 알고리즘과 좋은 접근 방식으로 개발되었으며 XNUMX명의 사용자가 있는 고성능 응용 프로그램이라고 가정합니다. 그렇다면 최대 부하에서 어떻게 고성능을 낼 수 있을까요?
선형 확장성이란 무엇입니까?
따라서 XNUMX에서 XNUMX에서 XNUMX으로 갈 수 있다면 선형 확장성이라고 합니다.
그리고 이를 달성하는 방식은 부하 분산 환경에서 알다시피 ASP를 배포합니다..NET core 로드 밸런서가 있는 애플리케이션에 점점 더 많은 서버를 추가합니다. 따라서 여기에 서버를 더 추가하면 트랜잭션 용량이 선형 방식으로 초당 요청 수 용량이 증가합니다. 그것을 달성할 수 있다면 동일한 성능을 달성할 수 있을 것입니다. 그리고 이것이 우리가 최고 부하에서 이러한 고성능을 달성할 수 있기를 바라는 오늘 발표의 목표입니다. 따라서 최고 부하에서 고성능이 없고 선형 애플리케이션이 없다면 어딘가에 병목 현상이 있음을 의미합니다. 따라서 특정 임계값을 초과하는 즉시 상자를 더 추가해도 상관 없습니다. 실제로 애플리케이션을 방해하는 어딘가에 병목 현상이 있기 때문에 속도가 느려질 수 있습니다. 따라서 비선형 확장성을 원하지는 않을 것입니다.
확장성이 필요한 앱은 무엇입니까?
요약하자면 어떤 유형의 애플리케이션이 확장 가능해야 합니까?
분명히 ASP.NET core 이것이 우리가 말하는 것입니다. 또한 ASP.NET 앱은 사용자가 인간임을 의미하는 웹 앱임을 의미하는 웹 서비스가 있을 수 있습니다. 웹 서비스는 다시 웹 앱입니다. 그들의 사용자는 다른 앱입니다. 마이크로서비스는 서버 측 애플리케이션에도 적용되는 비교적 새로운 개념입니다. 물론 여기에는 전체 애플리케이션을 다시 설계하는 작업이 포함됩니다. 어떻게 하는지는 다루지 않겠습니다. 여러분이 하고 있거나 회사에서 하고 있는 모든 것을 매핑할 수 있도록 유형 애플리케이션을 언급하고 있습니다. 마지막으로 일반 서버 응용 프로그램이 많이 있습니다. 이러한 서버 응용 프로그램은 일괄 처리를 수행할 수 있습니다. 예를 들어, 대기업이라면 은행이라면 백그라운드에서 배치 모드, 작업 흐름 모드로 많은 작업을 처리해야 할 수 있으며 이러한 작업은 서버 앱입니다.
확장성 문제 및 솔루션
따라서 이러한 다양한 유형의 애플리케이션은 모두 확장성을 처리할 수 있어야 합니다. 즉, 속도를 늦추지 않고 증가하는 모든 트랜잭션 로드를 처리할 수 있어야 합니다. 따라서 분명히 확장성 문제가 있습니다. 그렇지 않으면 우리는 이 대화를 나누지 않을 것입니다. 모든 것이 괜찮다면 좋은 소식은 애플리케이션 계층이 문제가 아니라 ASP라는 것입니다..NET core 응용 프로그램이 문제가 아니라 데이터 저장소입니다. 어떤 데이터를 만지고 있든 상관없이 성능 병목 현상이 발생합니다. 그리고 그것은 관계형 데이터베이스, 메인프레임 레거시 데이터 및 기타 여러 데이터입니다. 재미있게, NoSQL database많은 상황에서 당신이 할 수 없기 때문에 s가 항상 답은 아닙니다... 왜냐하면 NoSQL database 관계 데이터베이스를 포기하고 새 SQL 데이터베이스로 이동하도록 요청하거나 NoSQL database 다양한 기술 및 비기술적 이유로 수행할 수 없습니다. 그리고 이동이 어려우시면 NoSQL database, 무슨 소용이야? 오른쪽?
그래서 제 초점은 그림에서 관계형 데이터베이스로 이 문제를 해결해야 한다는 것입니다. 제가 말했듯이 여러 가지 이유로 관계형 데이터베이스를 사용해야 하기 때문입니다. 그리고 만약 당신이 그것에서 벗어날 수 없다면 NoSQL databases는 많은 상황에서 답이 아닙니다.
분산 캐시 배포
따라서 관계형 데이터베이스를 계속 사용하고 대신 애플리케이션에 분산 캐시를 배포해야 합니다.
다음은 그 모습입니다. 따라서 동일한 애플리케이션 계층이 있는 경우 트랜잭션 로드가 증가함에 따라 더 많은 서버를 추가할 수 있습니다. 이들 중 다수의 경우 웹 앱 및 웹 서비스라고 가정해 봅시다. 이들은 일반적으로 모든 웹 서버가 사용자로부터 동일한 로드를 받고 있는지 확인하는 로드 밸런서입니다. 서버 애플리케이션의 경우 밸런서가 많지 않을 수 있으며 애플리케이션의 특성에 따라 다를 수 있습니다. 그러나 실제로는 더 많은 서버를 추가할 수 있으며 여기에는 데이터베이스가 하나만 있습니다. 그리고 내가 말했듯이 일부가있을 수 있습니다 NoSQL database 일부 더 작은 전문 데이터의 경우 그러나 대부분의 데이터는 여전히 관계형입니다. 따라서 목표는 사이에 캐싱 계층을 배치하는 것이며 분산 캐시는 본질적으로 두 개 이상의 서버로 구성된 클러스터이며 이러한 서버는 저비용 서버입니다. 이들은 고급 데이터베이스 유형의 서버가 아니며 모든 것이 메모리에 저장됩니다.
왜 기억에? 메모리는 하드 디스크보다 훨씬 빠르기 때문입니다. 애플리케이션이 점점 더 많은 기능을 수행해야 하는 경우 이에 대해 절대적으로 명확해야 합니다. SSD든 HDD든 하드 디스크는 여러분을 죽일 것입니다. 메모리로 이동해야 합니다. 모든 것을 메모리에 저장해야 합니다. 그렇지 않으면 원하는 성능을 얻을 수 없습니다. 그리고 그것은 분산 캐시로 이동하는지 여부에 관계없이 메모리에 저장됩니다. 따라서 분산 캐시에는 두 개 이상의 서버가 있습니다. 그것은 클러스터를 형성하고 클러스터라는 단어는 모든 서버가 클러스터의 다른 서버에 대해 알고 리소스, 메모리, CPU 및 네트워크 카드를 풀링했음을 의미합니다. 따라서 이들은 하나의 논리적 용량으로 함께 가져오는 세 가지 리소스입니다.
메모리: 모든 서버에 RAM이 있으므로 고객이 사용한 일반적인 구성은 16~32GB의 RAM과 모든 캐시 서버입니다. 최소 16개, 16~32개를 권장합니다. 그런 다음 32개 이상으로 이동하는 대신 64 또는 128GB의 RAM을 각 상자에 추가해야 합니다. 메모리가 많을수록 CPU 용량을 늘려야 합니다. 더 많은 가비지 수집을 수행해야 합니다. .NET은 GC를 사용하기 때문에 더 많은 가비지 수집은 더 많은 CPU를 의미하거나 그렇지 않으면 가비지 수집이 병목 현상이 됩니다. 따라서 16기가의 32개 상자를 갖는 것보다 128~XNUMX개의 범위를 갖고 더 크지 않고 더 많은 상자를 갖는 것이 좋습니다. 그래서, 그것은 메모리입니다.
CPU는 분명히 두 번째입니다. 다시 말하지만 일반적인 구성은 약 8개의 코어 상자입니다. 고급 배포 중 일부는 약 16개의 코어를 사용하지만 상자당 8개의 코어로도 충분합니다. 내가 말했듯이 저렴한 서버. 그리고 네트워크 카드는 물론 여기에서 여기로 전송되는 모든 데이터가 네트워크 카드를 통해 전송되기 때문입니다. 이제 애플리케이션 계층에는 분명히 캐시 서버보다 더 많은 애플리케이션 서버가 있습니다. 그리고 다시, 일반적으로 우리가 권장하는 비율은 약 XNUMX:XNUMX 또는 XNUMX:XNUMX 비율입니다. 최소 XNUMX개의 캐시 서버가 있는 하나의 캐시 서버에 XNUMX개의 애플리케이션 서버. 따라서 여기에 XNUMX개의 애플리케이션 서버가 있고 XNUMX개의 네트워크 카드가 있으면 XNUMX대 XNUMX 비율의 네트워크 카드에 데이터를 보냅니다.
따라서 네트워크 카드는 캐시 서버에 적어도 하나의 기가비트 또는 10기가비트 네트워크 카드가 있어야 합니다. 그 외에는 그것들을 함께 끌어오기만 하면 됩니다. 최소 XNUMX개로 시작하고 최대 XNUMX개에 도달하면 일어날 일은 애플리케이션을 실행하는 것입니다. 모든 것이 정말 초고속으로 실행되거나 로드 테스트를 수행 중일 수 있습니다. 모든 것이 초고속으로 실행되고 부하가 증가합니다. 갑자기 서버 측에서 더 높은 CPU, 더 높은 메모리 소비를 보기 시작하고 응답 시간이 느려지기 시작합니다. 이것이 바로 관계형 데이터베이스에서 일어날 일입니다. 여기서 세 번째 상자를 추가하면 갑자기 또 다른 큰 안도감을 얻을 수 있습니다. 이제 다시 높은 처리량으로 시작하고 이제 점점 더 많은 트랜잭션을 추가할 수 있으며 최고조에 달할 것입니다. 그리고 나서 네 번째 상자를 추가합니다.
이것이 바로 이 그림이 계속 증가하는 방식이며 이것은 병목 현상이 되지 않으며 Never Say Never이지만 거의 절대 병목 현상이 되지 않습니다. 왜냐하면 점점 더 많은 서버를 추가할 수 있기 때문입니다. 그리고 여기에 더 많은 서버를 추가하면 데이터베이스로는 할 수 없는 이 캐시에 더 추가하게 됩니다. 이제 8020로드를 넣습니다. 실제로는 90%의 트래픽이 캐시로 가고 10%가 데이터베이스로 가는 것과 비슷합니다. 캐시에서 읽을 데이터가 점점 더 많아지기 때문입니다. 캐시가 처리해야 하는 몇 가지 다른 측면을 살펴보겠지만 이것은 기본적으로 그림이므로 분산 캐시가 필요한 이유입니다.
분산 캐시 사용
좋아요! 계속 진행하겠습니다. 이제 여러분이 분산 캐시 귀하의 지원서에서 가장 먼저 떠오르는 질문은 '그것으로 무엇을 해야 합니까?'입니다. 어떻게 사용합니까? 따라서 분산 캐시를 사용할 수 있는 세 가지 주요 범주가 있습니다.
다른 것들이 있지만 대부분의 토론에서 세 가지가 정말 높은 수준입니다.
앱 데이터 캐싱
첫 번째는 애플리케이션 데이터 캐싱입니다. 이것이 제가 지금까지 이야기해 온 것입니다. 데이터베이스에 있는 데이터가 무엇이든, 그것이 제가 애플리케이션 데이터라고 부르는 것입니다. 데이터베이스로 이동하지 않도록 캐싱하는 것입니다. 이제 염두에 두어야 할 점은 애플리케이션 데이터를 캐싱할 때 문제의 본질은 데이터가 두 위치에 존재한다는 것입니다. 캐시와 데이터베이스. 그리고 데이터가 두 곳에 존재할 때마다 무엇이 잘못될 수 있습니까? 동기화되지 않았습니다! 응! 따라서 데이터가 동기화되지 않을 수 있습니다. 따라서 데이터와 캐시가 데이터베이스와 동기화되지 않은 경우 많은 문제가 발생할 수 있습니다. 처음부터 백만 달러를 인출해야한다고 가정하면 두 번이나 인출 할 수 있지만.. 그것이 내 마음에 오는 첫 번째 문제입니다.
해당 문제를 처리할 수 없는 모든 캐시, 모든 분산 캐시는 읽기 전용 데이터로 제한됨을 의미합니다. 그러나 우리가 참조 데이터라고 부르는 것. 그리고 이것이 캐시 읽기 전용 데이터를 조회 테이블로 이해하기 시작하면서 캐싱이 시작된 방식입니다. 조회 테이블은 데이터의 약 10%입니다. 일부 응용 프로그램에서는 일반적인 응용 프로그램이 아닙니다. 데이터의 90%는 조회 데이터가 아닙니다. 트랜잭션 데이터입니다. 귀하의 고객, 귀하의 활동, 주문, 모든 것입니다. 따라서 모든 항목을 캐시할 수 없다면 데이터의 10%를 캐시할 수 있는 이점이 있습니다. 조회가 실제로 공정한 공유보다 더 많이 수행될 수 있습니다. 따라서 그 10%는 30%의 이점을 줄 수 있지만 여전히 데이터베이스로 이동해야 하는 데이터의 70%가 있습니다. 그러나 모든 데이터를 캐싱할 수 있다면 그러한 편안함을 얻을 수 있을 때만 가능한 것이므로 실질적인 이점을 얻을 수 있습니다.
ASP.NET Core 특정 캐싱
두 번째 사용 사례 또는 두 번째 사용 방법은 내가 ASP라고 부르는 것입니다..NET core 특정 캐싱 및 세 가지 방법이 있습니다. 하나는 가장 일반적으로 이해되는 세션입니다. ASP.NET에는 ASP가 있었습니다..NET core 가지고 있습니다. 그들은 여기에 있습니다. 일부 사람들은 세션을 사용하지 말아야 한다고 주장하지만 세션이 사라지지 않을 것이라고 생각합니다. 당신이 그들을 사용하는 경우 아무런 해가 없습니다. 그것들의 유일한 문제는 그것들을 어디에 저장하느냐입니다. 그것은 항상 ASP.NET의 문제였습니다. Microsoft가 제공한 스토리지 옵션은 모두 문제로 가득 차 있었습니다. 따라서 당시 유일한 옵션은 다행스럽게도 ASP.NET 시절에 사용자 지정 옵션으로 연결할 수 있는 분산 캐시를 사용하는 것이었습니다. ASP에서.NET core, Microsoft는 기본 제공 기능이 없거나 독립 실행형 인 메모리와 같은 이미지가 있지만 곧바로 IDistributedCache 또는 다음과 같은 타사 분산 캐시에 연결할 수 있는 사용자 지정 세션 공급자 NCache.
세션은 첫 번째이고 두 번째는 응답 캐싱입니다. 응답 캐싱에 대해 모르는 사람이 누구인지 말하려고 했지만 그것은 좋은 질문 방법이 아닙니다. 응답 캐싱은 최신 버전의 출력 캐시와 비슷하지만 보다 표준 기반입니다. 캐시할 수 있는 페이지 출력이며 이에 대해 살펴보겠습니다. 하지만 미들웨어로 분산 캐시를 캐시하고 연결할 수도 있습니다.
그리고 세 번째는 라이브 웹 앱인 신호 또는 애플리케이션이 있는 경우입니다. 라이브 웹 앱은 예를 들어 모든 주가 변동을 지속적으로 전파해야 하는 주식 거래 애플리케이션이 있고 수십만 명의 클라이언트가 있는 앱입니다. 그들은 모두 연결되어 있으므로 모두 캐싱 또는 애플리케이션 계층에 연결된 상태를 유지합니다. 모든 웹 요청에 대해 새 소켓 연결이 열리는 일반 HTTP와 다릅니다. 여기서 소켓 연결은 열린 상태로 유지되고 이벤트는 서버에서 전파됩니다. 따라서 SignalR에서 더 높은 트랜잭션과 많은 수의 사용자가 있을 때 로드 밸런싱된 웹 형식을 가져야 하지만 소켓이 열려 있기 때문에 모든 서버가 자체 클라이언트와 통신할 것입니다. 클라이언트 또는 모든 서버에는 서로 다른 클라이언트 집합이 있으므로 데이터를 공유해야 합니다. 따라서 해당 데이터는 백플레인을 통해 공유되고 해당 백플레인은... 분산 캐시를 연결하는 위치입니다. 나는 그 세부 사항에 대해 다루지 않을 것입니다. 처음 두 개는 살펴보고 세 번째는 다루지 않겠습니다.
이제 ASP에 대한 구체적인 사항.NET core 특정 캐싱은 데이터가 캐시에만 존재한다는 것입니다. 이것은 내가 데이터베이스에 넣지 말라고 말한 것입니다. 필요 없습니다. 이것은 임시 데이터입니다. 20분, 30분, 2시간, XNUMX시간 동안만 필요하며 그 이후에는 데이터가 사라져야 합니다. 따라서 일시적인 경우 캐시에만 존재해야 하며 데이터가 캐시에만 존재하고 메모리 내 캐시인 경우 무엇이 잘못될 수 있습니까? 모두 메모리에 있기 때문에 데이터가 손실될 수 있습니다. 메모리는 휘발성입니다. 따라서 좋은 분산 캐시는 이러한 상황을 처리해야 합니다. 물론 복제가 필요합니다.
Pub/Sub 메시징 및 이벤트
세 번째 사용 사례는 워크플로 유형의 작업을 수행하는 데 필요한 많은 애플리케이션입니다. 마이크로서비스가 그 좋은 예입니다. 그들은 활동을 조정해야 하지만 마이크로서비스가 주제는 아니지만 ASP도 마찬가지입니다..NET core 응용 프로그램은 때때로 그렇게 해야 합니다. 그래서, 게시/구독 메시징 다시 한 번 기억하십시오. 이 모든 상자가 이 중복 인메모리 인프라에 연결되는 인프라가 준비되어 있기 때문입니다. 그렇다면 게시/구독 메시징에도 사용하지 않는 이유는 무엇입니까?
이것이 세 가지 일반적인 사용 사례입니다. 따라서 다음 세 가지 방법을 사용해야 합니다. NCache 또는 이익을 얻고자 하는 경우, 이익을 극대화하려는 경우 분산 캐시.
실습 데모
그래서 실제로 어떻게 사용하는지 알아보기 전에 분산 캐시가 어떤 모습인지 실제로 보여드리고 싶습니다. Azure를 환경으로 사용하고 사용할 예정입니다. NCache. 그리고 간단한 데모에 불과합니다...
환경 설정
그래서 저는 Azure에 로그인했습니다. XNUMX개의 VM이 있는데 이것도 모두 .NET core.
따라서 Azure에는 XNUMX개의 VM이 있습니다. 이 중 두 개는 기본적으로 캐시 서버 VM으로 사용할 것입니다. 이 두 개는… Windows 클라이언트 하나와 Linux 클라이언트 하나를 갖게 될 것입니다. 그래서 만약 당신이 가지고 있다면 .NET core 리눅스를 지원합니다. 당신이 가지고 있다면 .NET core 응용 프로그램으로 이것을 Linux에 배포할 수 있습니다. 이제, NCache, 다시 말하지만 나는 마케팅을 하는 것이 아닙니다. NCache. 그러나 의 경우 NCache, 그것은 .NET core 따라서 Windows 또는 Linux, 서버 및 클라이언트 모두에서 실행할 수 있습니다.
좋아요! 시작하겠습니다... 그래서 저는 이 클라이언트인 Windows 클라이언트 상자에 로그인했습니다. 이제 계속해서 캐시를 생성하겠습니다.
클러스터형 캐시 생성
그래서 저는 이 도구를 사용할 것입니다. NCacheWalk Through California 프로그램, NCache 매니저 실제로 오픈 소스와 함께 제공되지 않습니다. 이에 상응하는 명령줄이 있지만 여기서는 게을러졌습니다. 그래서 저는 이만 사용하겠습니다. NCache 관리자이지만 동일한 기능입니다. 기능이 바뀌지 않아서 그냥 실행했습니다 NCache 관리자. 새 캐시를 생성한다고 말할 것입니다. 방금 캐시 이름을 지정했습니다. 모든 캐시에는 이름이 지정됩니다. 이를 데이터베이스에 대한 연결 문자열로 생각한 다음 토폴로지를 선택합니다. 토폴로지로 들어가지는 않겠지만 캐시가 이러한 모든 요구 사항을 처리하기 위해 수행해야 하는 작업에 대해 끝까지 살펴보겠습니다. 따라서 파티션 복제본 캐시 토폴로지를 사용하겠습니다. 비동기 복제. 첫 번째 캐시 서버를 추가하겠습니다. 10.0.0.4와 두 번째는 5입니다. 그래서 두 개의 캐시 서버가 있습니다. 모두 기본값으로 두겠습니다. 나는 퇴거와 다른 모든 사람들에게 갈 것입니다.
이제 두 개의 클라이언트를 지정하겠습니다. 10.0.0.6 및 7. 여기로 와서 캐시를 시작하겠습니다. 따라서 하나의 서버 대신 클러스터를 구성하는 여러 서버가 있고 캐시 서버 클러스터를 만든 다음 클라이언트를 할당하는 데이터베이스와 같다고 생각하십시오. 클라이언트를 실행할 수 있기 때문에 클라이언트를 할당할 필요는 없지만 더 많은 유연성을 제공하기 때문에 여기에서 수행하겠습니다.
스트레스 시뮬레이션 및 캐시 통계 모니터링
그런 다음 클라이언트를 테스트하고 싶습니다. 그래서 저는 고객입니다. 나는 10.0.0.6이라고 생각합니다. 어느 쪽인지 확인하겠습니다. 제 생각에는 10.0.0.6인 것 같아요. 어서 해봐요! 다시 말하지만, Azure 가상 네트워크 내에서 모든 작업을 수행하므로 클라이언트는 실제로 애플리케이션 서버이고 캐시는 이제 모두 함께 있습니다. 의 경우 NCache 당신은 이것을 얻을 수 있었다 azure marketplace. 따라서 .6은 Windows 클라이언트입니다. 이제 PowerShell을 시작하고 볼 수 있는지 확인하겠습니다. 좋아요! 좋아요! 따라서 이 클라이언트가 캐시와 통신할 것이고 이제 각 캐시 서버에서 초당 약 XNUMX개의 요청을 수행하고 있음을 알 수 있습니다. 부하를 좀 더 추가하겠습니다. 다른 PowerShell을 열고 클라이언트의 다른 인스턴스를 강조하겠습니다. 이제 서버당 약 XNUMX~XNUMX개 이상으로 올라가는 것을 볼 수 있습니다.
이제 해보자... 실제로 해볼게... 그래서 여기에서 명령 프롬프트를 열었습니다. Linux 상자에 로그인하겠습니다. 이런! 그리고 미안! 여기서 PowerShell을 시작합니다. 클론의 부분 라이브러리를 가져와야 합니다. NCache 그리고 동일한 스트레스 데모 캐시를 수행할 것이므로 다음 작업을 수행할 것입니다. 이 작업을 수행하기 전에 보시다시피 서버당 약 XNUMX~XNUMX개를 수행하고 있습니다. 이것을 Linux 기반 클라이언트로 추가하여 캐시와 통신합니다. 이제 갑자기 서버당 거의 XNUMX개의 요청이 있습니다.
그래서 저는 두 대의 서버에서 초당 약 1개의 요청을 수행하고 있습니다. 내가 말했듯이, 당신은 점점 더 많은 부하를 추가할 수 있고 당신이 세 번째를 추가할 두 개의 상자를 최대로 한 다음 네 번째를 추가할 수 있습니다. 그래서 그것은 그렇게 간단하고 다시 이것은 시뮬레이션입니다. 스트레스 테스트 도구와 같은 실제적인 것입니다. 그래서 이것은 당신이 명심해야 할 것입니다. 이제 실제 캐시를 계속 사용하겠습니다. 스트레스 테스트 프로그램입니다. 바이트 배열처럼 넣습니다. XNUMXk 데이터를 넣는 것 같아요. 추가하고, 업데이트하고, 얻습니다. 따라서 실제 애플리케이션을 시뮬레이션하고 우리가 이야기한 대로 읽기와 쓰기의 비율을 확인하기 위해 변경할 수 있는 매개변수가 있습니다. 그리고 이것은 우리가 제공하는 도구입니다. NCache, 자신의 환경에서 실제로 테스트할 수 있도록 합니다. 그래서, 방법을 보려면 NCache 애플리케이션을 마이그레이션하는 데 실제로 많은 시간을 소비하기 전에 실제로 수행됩니다. 빨리 넘어가겠습니다. 나는 그것을 실행하고 있다고 생각합니다.
ASP.NET Core 세션 저장
이제 캐시가 어떻게 생겼는지, 어떻게 더 많은 클라이언트를 추가하고 더 많은 부하를 추가할 수 있는지 살펴보았으므로 매우 간단합니다. 따라서 캐시를 사용하는 가장 쉬운 방법은 캐시에 세션을 넣는 것입니다. 세션의 경우 두 가지 작업을 수행할 수 있습니다.
IDistributedCache 공급자를 사용할 수도 있습니다. 의 말을하자 NCache 하나 있습니다. 지정하자마자 NCache IDistributeCache, ASP로.NET core 세션 저장에 사용하기 시작합니다. 그리고 그 중 일부를 실제로 보여드리겠습니다. 이 ASP가 있습니다..NET core 애플리케이션. 여기에서 볼 수 있듯이. 내 구성 서비스에서 나는 이것을 지정하고 있습니다. NCache 내 분산 캐시 공급자. 따라서 이 작업을 수행하자마자 시작되고 표준 세션을 사용하고 있으며 이러한 표준 세션은 현재 사용 중인 IDistributedCache를 사용합니다. NCache. 따라서 보유하고 있는 분산 캐시 제공자가 무엇이든 그것이 여러분이 해야 할 전부입니다. 보시다시피 아주 작은 코드 변경과 전체 애플리케이션이 자동으로 모든 세션이 즉시 분산 캐시에 저장됩니다.
public IConfigurationRoot Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
// Add framework services.
services.AddMvc();
//Add NCache as your IDistributedCache so Sessions can use it for their storage
services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
//Add regular ASP.NET Core sessions
services.AddSession();
}그리고 우리가 본 것 중 하나는 많은 고객이 데이터베이스에 세션을 저장하고 문제가 있을 때 다음과 같은 것을 연결하는 것입니다. NCache 즉각적이고 그들이 보는 이점, 현저한 개선은 즉각적입니다. 최소한의 노력으로 최대의 이득을 얻을 수 있습니다. 물론 애플리케이션 직접 캐싱도 있기 때문입니다.
제 생각에는 몇 가지를 건너뛰겠습니다... 따라서 세션을 지정할 수 있는 여러 가지 방법이 있습니다. 하나는 IDistributedCache이고, 두 번째는 사용자 지정 세션 공급자를 실제로 사용할 수 있다는 것입니다. NCache 또한 이 모든 것이 오픈 소스입니다. 그런 다음 응답 캐싱을 위해 다시 동일한 작업을 수행합니다. 당신은 지정 NCache 분산 캐시로 사용되며 자동으로 응답 캐싱을 위한 캐시가 됩니다. 자세한 내용은 다루지 않겠습니다.
ASP.NET Core 앱 데이터 캐싱
나는 당신이 이 주제에 대해 조금 더 기초를 다지기를 바랍니다. 따라서 애플리케이션 데이터 캐싱을 할 때 세션과 달리 이제 실제로 API 프로그래밍을 해야 합니다. 엔티티 프레임워크 코어를 수행하지 않는 한.
그래서 예를 들어 다음과 같은 경우 NCache, 다시 오픈 소스에는 EF 코어 공급자가 있습니다. 그래서 우리는 EF core에 대한 확장 메서드를 구현했습니다. 따라서 실제로 연결할 수 있습니다. NCache open source 일반 EF 핵심 쿼리를 사용하고 마지막에 캐시 또는 데이터베이스에서 말할 수 있습니다. 자동으로 항목을 캐시하기 시작하는 확장 방법일 뿐입니다. 캐시하려는 항목과 캐시하지 않으려는 항목을 완전히 제어할 수 있습니다. 한번 보세요. 정말 강력한 방법입니다.
내가 권장하는 EF 코어를 수행하는 경우. 제 생각에는 모든 ASP에 대해.NET core 애플리케이션, 모든 데이터베이스 프로그래밍은 특히 EF 코어가 이전 EF보다 훨씬 좋은 아키텍처이기 때문에 EF 코어를 통해 수행되어야 합니다. 그래서, 그것은 그것을 하는 한 가지 방법입니다.
다른 하나는 실제로 만들 수 있다는 것입니다. 하나의 캐싱 솔루션에 얽매이지 않는 유연성을 제공하는 IDistributedCache API 또는 인터페이스를 사용할 수 있지만 비용이 발생합니다. 매우 기본적입니다. get 입력만 있고 기본적으로 제거도 있습니다. 그게 전부입니다. 그리고 우리가 이야기한 모든 것, 캐시를 데이터베이스와 동기화할 수 없다면 그 모든 것을 잃게 됩니다. 따라서 이러한 모든 기능을 활용하려면 실제로 모든 기능을 지원하는 API로 이동해야 합니다. 그리고 다시 말하지만, 오픈 소스 캐시에 커밋할 것이기 때문에 일반적으로 그렇게 하는 것이 더 쉽지만 애플리케이션 직접 캐싱, API는 매우 간단하고 키가 있고 값이 있습니다. 값은 귀하의 개체입니다.
캐시를 최신 상태로 유지
이제 캐시를 최신 상태로 유지할 수 있는 항목에 대해 설명하겠습니다. 정말 소중한 정보죠? 너 뭐하니?
거의 모든 분산 캐시가 가장 먼저 하는 일은 만료입니다! 당신은 절대적인 표현을 합니다. 캐시에 무엇을 넣든 지금부터 XNUMX분 후에 캐시에서 제거한다고 말합니다. 따라서 XNUMX분 안에 보관하는 것이 안전합니다. XNUMX분 안에 다른 사람이 업데이트한 후 업데이트하는 사람은 저뿐이라고 생각합니다. 그래서, NCache 가지고 있고, 다른 사람들도 가지고 있습니다. 임시... 세션과 같은 임시 데이터에 대한 슬라이딩 표현이 있습니다. 사용을 마친 후 일정 시간 동안 건드리지 않으면 세션이라고 가정하고 사용자가 20분 동안 활동이 없으면 세션이 종료됩니다. 만료됩니다. 그래서 똑같은 일이 일어납니다. 만기는 거의 모든 사람이 가지고 있습니다.
다음은 데이터베이스와 동기화된 캐시입니다. 이것은 캐시가 데이터베이스를 모니터하도록 허용하는 기능입니다. 따라서 실제로… 항목을 추가할 때 NCache, 허용하는 SQL 종속성을 가질 수 있다고 가정해 봅시다. NCache 모니터링합니다. SQL 종속성은 우리가 사용하는 SQL 서버 ADO.NET 기능입니다. SQL 종속성을 사용하면 다음을 허용하는 SQL 문 또는 저장 프로시저를 지정할 수 있습니다. NCache SQL 서버 데이터베이스, 해당 특정 데이터 세트를 모니터링합니다. 그리고 해당 데이터 세트에 변경 사항이 발생하면 SQL 서버가 이를 알립니다. NCache 모든 캐시는 캐시에서 해당 데이터를 제거하거나 해당 동기화를 읽기 기능과 결합하면 데이터를 다시 로드합니다. 따라서 캐시된 고객 개체가 있고 SQL 종속성이고 해당 고객이 고객 트랜잭션 데이터인 데이터베이스에서 변경되어 자주 변경될 것이라고 가정해 보겠습니다. read-through를 사용하고 식 또는 데이터베이스 동기화.
이제 갑자기 캐시가 데이터 모니터링을 담당합니다. 이를 수행할 수 있는 세 가지 방법이 있습니다. SQL 종속성, DB 종속성 및 봉인은 CLR 저장 프로시저입니다. 자세한 내용은 다루지 않겠습니다. 저희 웹사이트에 가셔서 읽으실 수 있습니다. 그러나 가장 중요한 것은 데이터베이스와 캐시 동기화 기능이 없는 경우 읽기 전용 및 정적 데이터로 제한된다는 것입니다. 그런 다음 모든 것을 제한하고 다시 이 캐시를 비관계형 데이터 소스와 동기화할 수 있습니다.
그리고 세 번째는 관계형… 대부분의 경우 일대다 일대일 관계가 있는 관계형 데이터를 캐싱하게 될 것입니다. 예를 들어, 한 고객이 여러 주문을 가지고 있다고 가정해 보겠습니다. 고객을 제거하면 데이터베이스에서 주문을 삭제했을 수 있으므로 주문도 캐시에 남아 있어서는 안 됩니다. 따라서 그렇게 하지 않으면 응용 프로그램에서 이 모든 작업을 수행해야 하지만 ASP.NET 캐시 개체에는 키 종속성 기능이라는 이 기능이 있습니다. NCache 여러 캐시 항목 간에 일대다 또는 일대일 관계를 가질 수 있고 한 항목이 업데이트되거나 제거되면 다른 항목이 자동으로 제거되도록 구현했습니다. 따라서 이 네 가지가 결합되어 캐시를 최신 상태로 유지하고 데이터베이스와 일관성을 유지할 수 있습니다. 그리고 이것이 데이터 캐시를 시작할 수 있게 해주는 것입니다. 이것이 첫 번째 이점입니다.
리드스루 및 라이트스루
두 번째는 read-through 및 write-through를 사용할 수 있으면 응용 프로그램이 단순화된다는 것입니다.
내가 말했듯이 Read-through는 자동 재로드를 위해 read-through를 결합할 수 있습니다. 이는 read-through가 없으면 애플리케이션이 수행할 수 없는 것입니다. 그리고 write-through는 캐시를 업데이트할 수 있고 캐시는 특히 권한이 있는 경우 데이터베이스를 업데이트할 수 있습니다. 다시 성능에 대해 이야기하고 있습니다. 따라서 모든 업데이트는 데이터베이스에 적용되어야 합니다. 음, 업데이트는 캐시에서 읽는 것에 비해 느릴 것입니다. 그래서 업데이트를 캐시에 위임하고 내가 캐시를 업데이트하겠다고 말할 수 있다면, 가서 나를 위해 데이터베이스를 업데이트하는 것은 어떻습니까? 나는 그것이 안전하다는 것을 알고 있습니다. 그리고 우리는 최종 일관성 모델에 대해 작업할 것입니다. 분산 시스템은 여러분이 희생하거나 일관성에 대해 더 관대해지고 최종 일관성 모델을 사용하는 것입니다. 즉, 이 시점에서 일관성이 없더라도 캐시가 업데이트되기 때문에 데이터베이스가 그렇지 않고 몇 밀리초 내에 업데이트될 것입니다. 그리고 일부 데이터는 그렇게 할 여유가 없지만 많은 데이터는 할 수 있습니다.
따라서 바로 뒤에 작업을 수행하면 갑자기 업데이트가 매우 빨라져 응용 프로그램에서 데이터베이스 업데이트 비용을 발생시킬 필요가 없습니다. 캐시는 분산 캐시이기 때문에 수행하며 배치로 흡수할 수 있고 다른 캐시가 있습니다. 따라서 일단 이 작업을 시작하면 이제 많은 데이터를 캐시할 수 있습니다.
데이터 그룹화
점점 더 많은 데이터를 캐시하면 캐시가 거의 데이터베이스만큼 풍부해집니다. 이는 거의 모든 데이터를 캐시한다는 의미입니다.
거의 모든 데이터를 캐시하면 키 값만으로는 물건을 찾기에 충분하지 않습니다. 물건을 검색할 수 있어야 합니다. AppFabric 예전에는 그룹과 하위 그룹, 태그라는 이름의 태그, 그런데 NCache open source 이 AppFabric 싸개. 그럼 받으신 분들은 AppFabric 로 이동할 수 있습니다 NCache 무료로. 따라서 그룹화를 통해 데이터를 쉽게 가져올 수 있습니다.
데이터 찾기
SQL 검색을 사용하면 도시가 뉴욕인 내 모든 고객을 제공하는 것과 같은 항목을 찾을 수 있습니다. 이제 캐시에서 데이터베이스 유형의 쿼리를 수행합니다. 왜? 캐시에 많은 데이터가 포함되어 있지 않기 때문입니다.
점점 더 많은 메모리를 사용하고 있기 때문에 전체 패러다임이 바뀌고 있습니다. 다시 말하지만 데이터베이스는 마스터입니다. 따라서 캐시에는 여전히 일시적인 기간 동안만 캐시가 있습니다.