보스턴 코드 캠프 31
ASP 최적화.NET Core 분산 캐시의 성능
이크발 칸
사장 및 기술 전도사
ASP.NET Core 트래픽이 많은 웹 애플리케이션 개발에 빠르게 인기를 얻고 있습니다. ASP 최적화 방법 알아보기.NET Core 오픈 소스 .NET 분산 캐시를 사용하여 속도 저하 없이 극단적인 트랜잭션 로드를 처리하는 성능. 이 강연에서는 다음을 다룹니다.
- ASP 개요.NET Core 성능 병목 현상
- 분산 캐싱 개요 및 성능 문제 해결 방법
- 애플리케이션에서 분산 캐싱을 사용할 수 있는 위치
- 몇 가지 중요한 분산 캐시 기능
- 오픈 소스를 사용한 실습 예제 NCache 분산 캐시로
알겠습니다. 감사합니다. 모두 제 말을 잘 들을 수 있나요? 알겠습니다. 슬라이드를 포함하는 것을 잊었습니다. 모든 스폰서에게 감사드립니다. 웹사이트로 이동하여 모든 스폰서의 로고를 보여드리겠습니다. 그나저나 우리도 그 중 하나이니 이것도 마지막에 보여드리겠습니다. 그것이 주최측이 우리에게 말한 것입니다. 그래서 저는 이 주제를 살펴보고 가능하면 이 대화를 더 대화식으로 유지하고 싶습니다. 그러니 질문이 있으시면 저를 멈추게 해주세요. 모든 것이 녹음되고 있는지 확인하겠습니다.
그래서 오늘의 주제는 ASP를 최적화하는 방법입니다..NET core 분산 캐싱으로 애플리케이션 성능? 라는 오픈 소스 제품을 사용하겠습니다. NCache. 여기 얼마나 많은 사람들이 NCache 전에? 좋은 숫자입니다. 좋아, 내가 사용할거야 NCache 예로서. 이 이야기는 NCache, ASP에 관한 것입니다..NET Core 성능과 캐싱을 어떻게 사용할 수 있습니까? 그래서 ASP 때문에 여기 온 것이 확실합니다..NET core 대중화되고 있습니다. 새로운 경량 아키텍처, 크로스 플랫폼 기술, .NET의 재설계는 오픈 소스입니다. ASP.NET 레거시 응용 프로그램도 ASP로 이동하고 있습니다..NET core. ASP.NET core .NET에서 웹 응용 프로그램을 개발하는 데 사용할 주요 기술이 될 것입니다.
그래서 점점 더 많은 사람들이 확장성이 필요한 애플리케이션을 개발하고 있습니다. 그래서 ASP.NET core 물론 확장성도 필요합니다. 확장성이 무엇인지 빠르게 정의하겠습니다. 여러분 대부분이 이것을 이미 알고 있다고 확신하지만 완전성을 위해 이것을 정의하겠습니다.
확장성이란 무엇입니까?
확장성은 응답 시간이 정말 좋은 애플리케이션이 있고 XNUMX명의 사용자와 정말 좋은 성능을 발휘하는 경우 XNUMX만 명의 사용자와 동일한 성능을 유지할 수 있다면 애플리케이션이 확장 가능하다는 것입니다. 애플리케이션이 XNUMX명의 사용자와 제대로 작동하지 않는 경우 여기에서 다루지 않을 다른 문제가 있는 것입니다. 그래서 XNUMX명의 사용자에서 XNUMX만 또는 XNUMX만 명의 사용자에 이르기까지 그 좋은 성능을 유지할 수 있는 방법에 대해 이야기하겠습니다.
선형 확장성
선형 확장성이란 로드가 증가함에 따라 프로덕션 환경에 서버를 추가할 수 있고 서버를 추가함에 따라 트랜잭션 용량이 증가하는 방식으로 애플리케이션이 설계됨을 의미합니다. 선형 확장성. 선형 확장성을 유지할 수 없다면 일종의 병목 현상이 있는 것입니다. 즉, 서버를 더 추가하면 애플리케이션이 곧 직면하게 될 것입니다. 병목 현상이 발생하면 병목 현상에 대해 이야기하겠습니다.
다음 애플리케이션에는 확장성이 필요합니다.
그렇다면 어떤 애플리케이션에 확장성이 필요할까요? 일반적으로 서버 응용 프로그램은 웹 응용 프로그램, ASP.NET core, 다른 웹 응용 프로그램에서 사용하는 웹 서비스. 웹 서비스는 외부 응용 프로그램에서 사용하는 독립 응용 프로그램일 수도 있고 개발 중인 웹 응용 프로그램의 일부일 수도 있습니다. 트랜잭션이 많은 경우 확장성도 필요합니다.
마이크로서비스는 이제 새로운 유행어가 되고 있습니다. 이것이 바로 애플리케이션을 재설계하기를 원하는 방식입니다. 마이크로서비스는 또한 서버 측 기술에 적용되며 트랜잭션이 많은 애플리케이션에 사용되며 확장성이 필요합니다. 다른 서버 응용 프로그램의 경우 많은 대규모 조직이 백엔드에서 일괄 처리를 수행하며 백엔드에서 워크플로를 수행해야 합니다. 많은 트랜잭션을 처리해야 하는 많은 백엔드 서버 애플리케이션은 확장성도 필요합니다. 따라서 귀하의 회사 또는 귀하가 이러한 유형의 응용 프로그램에 종사하고 있고 좋은 성과를 거두고 싶다면 이것이 귀하를 위한 이야기입니다.
확장성 문제
이제 이러한 애플리케이션에 확장성이 필요하다는 것을 확인했으므로 확장성 문제가 있습니까? 예, 있습니다. 애플리케이션 계층인 ASP에는 없습니다..NET core 애플리케이션에서는 트랜잭션 로드가 증가함에 따라 더 많은 서버를 매우 쉽게 추가할 수 있으며 일반적으로 애플리케이션 계층 앞에 로드 밸런서가 있어 트래픽을 모든 서버에 고르게 전달하고 점점 더 많은 사용자가 있을 때 추가하기만 하면 됩니다. 상자가 더 있어도 문제 없습니다. 물론 문제는 데이터 저장소 또는 데이터베이스입니다. 이것이 관계형 데이터베이스, 메인프레임이고 이것이 그 이유 중 하나입니다. NoSQL database관심을 끌기 시작했지만 대부분의 상황에서 기술적 및 비기술적 이유로 여전히 관계형 데이터베이스를 사용해야 하는 것으로 밝혀졌습니다. 그래서 여러분이 수행했거나 수행하고 있는 대부분의 응용 프로그램을 살펴보면 .NET의 경우 관계형 데이터베이스를 사용하게 됩니다. 물론 가장 인기 있는 것은 SQL 서버입니다. 그래서, 당신이 a를 사용할 수 없다면 NoSQL database, 확장성에 도움이 되는 것이 무슨 소용이 있습니까? 그 이유는 NoSQL database 관계형 데이터베이스를 포기하고 데이터를 NoSQL, 일부 데이터의 경우 할 수 있지만 많은 비즈니스 데이터의 경우 할 수 없습니다. 모든 고객, 계정, 모든 활동은 여전히 관계형 데이터베이스에 남아 있어야 합니다. 따라서 그림의 관계형 데이터베이스로 이 확장성 문제를 해결해야 합니다. NoSQL database 당신이 그것을 사용할 수 없기 때문에 항상 답은 아닙니다.
솔루션(분산 캐싱)
따라서 이를 해결하는 방법은 물론 분산 캐시를 사용하는 것이며 이것이 분산 캐시가 사용자 환경에 배포되는 방식입니다.
따라서 이것은 응용 프로그램 계층입니다. 경우에 따라 트래픽을 모든 응용 프로그램 서버로 보내는 로드 밸런서가 여기 앞에 있을 수 있습니다. 경우에 따라 로드 밸런서가 없을 수 있습니다. 일부 백엔드 애플리케이션이기 때문에 로드가 공유되는 다른 방법이 있을 수 있지만 어쨌든 애플리케이션을 실행하는 여러 서버가 있습니다. 따라서 이것은 매우 확장 가능하지만 데이터베이스에 계속해서 더 많은 데이터베이스를 추가할 수는 없습니다. 이제 관계형 데이터베이스 회사는 예를 들어 훨씬 더 빠른 인메모리 테이블을 보유하는 등 자체 확장을 위해 최대한 많은 노력을 기울이고 있습니다. 내 생각에 SQL 서버는 이러한 읽기 전용 복제본의 개념을 도입하지 않은 것 같습니다. 따라서 메모리 내 테이블을 읽기 전용 복제본과 결합하면 성능이 향상되지만 보시다시피 이것. 더 많은 복제본을 생성할수록 모든 복제본에서 업데이트해야 하는 항목을 업데이트할 때마다 업데이트하는 측면에서 골칫거리가 더 커집니다. 따라서 확장성으로 최상의 성능을 달성하려면 복제본이 하나만 있는지 확인해야 합니다. 따라서 모든 데이터 조각의 마스터 복사본 하나와 복제본 하나는 동시에 확장할 수 있어야 합니다. 따라서 그들이 그렇게 할 수 없는 이유는 관계형 데이터베이스가 분산 캐시가 할 수 있는 것과 같은 방식으로 분할될 수 없기 때문입니다. NoSQL database 분산 캐시와 NoSQL 관계형 데이터베이스와는 매우 다른 디자인이지만 결국 애플리케이션 계층과 데이터베이스 사이에 캐싱 계층으로 분산 캐시를 넣어야 합니다.
그렇다면 구성이란 무엇입니까? 따라서 일반적으로 이들은 매우 비싼 상자가 아닙니다. 이들은 일반적으로 8코어에서 16코어 박스, 많은 메모리 16~32기가 메모리, 1~10기가비트 네트워크 카드입니다. 때로는 두 개의 네트워크 카드가 있습니다. 하나는 클러스터링을 위한 것이고 다른 하나는 일종의 클라이언트를 위한 것입니다. 그들 중 하나만 있거나 거의 없습니다. 따라서 이 문제를 해결할 다른 방법은 없습니다. 우리는 고객에게 .NET 환경에서 64기가 이상의 RAM이 있는 경우 가비지 수집을 통해 메모리를 수집하고 점점 더 많은 메모리를 수집함에 따라 수집해야 하기 때문에 상자당 64기가 이상의 RAM을 얻지 말라고 말합니다. 더 많은 처리 능력이 필요한 것보다. 그래서, 당신은 정말 비싼 상자를 얻기 시작하는 동일한 문제에 들어갑니다. 32, 16에서 32비트, 16에서 32기가 메모리를 얻는 것이 더 좋지만 더 많은 상자가 더 저렴합니다.
분산 캐시는 어떻게 작동합니까?
그렇다면 분산 캐시는 무엇을 합니까? 그것은 실제로 클러스터를 구축하고 다시 한 번 NCache 관점, 또한 같은 다른 사람이 있습니다 Redis 비슷한 일을 하지만 다른 방식으로 하는 것입니다. 따라서 분산 캐시는 클러스터를 구축할 것입니다. 이것은 TCP 기반 클러스터이며 클러스터에서 가장 중요한 것은 데이터베이스가 다운되는 것을 원하지 않고 프로덕션 환경에서 캐시가 중단되는 것을 원하지 않는다는 것입니다. 내려가거나. 따라서 이 클러스터는 가용성이 높아야 합니다. 따라서 고객에게 가용성을 높이는 가장 좋은 방법은 모든 노드가 동등한 시민이고 모든 노드가 다운되거나 더 많은 상자를 추가할 수 있는 P4P 아키텍처를 갖추도록 하는 것입니다. 복잡한 문제와 고가용성 문제가 발생하기 때문입니다. 따라서 리소스, 메모리, CPU 및 네트워크 카드를 리소스로 풀링했습니다. 따라서 더 추가함에 따라 점점 더 많은 트래픽 또는 더 많은 트랜잭션이 발생한다고 가정해 봅시다. 이후에는 더 많은 서버를 1:5, 1:XNUMX 비율로 추가합니다. 일반적으로 더 많은 상자를 추가합니다. 최소 XNUMX개의 캐시 서버를 추가한 다음 계속 추가하므로 XNUMX개로 시작하면 점점 더 많은 부하가 발생하기 시작하고 갑자기 모든 것이 느려지기 시작하고 세 번째 상자를 추가하면 모든 것이 개선됩니다. 더 많은 상자를 로드하고 추가하면 여기에서 특정 지점까지 속도가 느려지기 시작합니다. 네 번째 상자를 추가하면 그림이 시작됩니다.
이것이 선형적으로 확장되는 방식입니다. 이론상 무제한은 없지만 더 많은 상황에 맞게 확장됩니다. 병목 현상이 없는 무제한 방식으로 확장됩니다. 따라서 데이터베이스에 병목 현상이 발생하지 않도록 할 수 있습니다. 따라서 이것은 애플리케이션 아키텍처의 필수 모범 사례가 되었습니다. 트랜잭션이 많은 응용 프로그램을 수행하는 경우 분산 캐싱을 통합해야 하며 이것이 유일한 방법이기 때문에 성능을 달성할 수 있습니다. -분산되기 때문에 메모리와 확장성. 가기 전에 이것에 대해 질문이 있습니까? 사실 의 경우 NCache 너는 할 수있어. NCache .NET 및 Java를 지원하지만 Python과 같은 다른 응용 프로그램이 있는 경우 사용할 수 없습니다. NCache, 다른 캐싱 솔루션을 사용해야 하지만 애플리케이션은 확장 가능한 환경에 있어야 합니다. 기본적으로 어떤 언어를 사용하든 기능은 동일하게 유지됩니다. .NET 애플리케이션인 경우 몇 가지 이점이 있습니다. NCache 전체 .NET 스택, .NET 과정 스택이라는 .NET 관련 이점을 많이 제공하므로 매우 적합합니다. 메모리 내 데이터 그리드라고 하는 Java 측에도 유사한 제품이 있으므로 Java 스택에 매우 적합합니다. 예를 들어 몇 가지 정보를 공유하겠습니다. 그래서, NCache Java API가 있지만 Java API를 사용하는 유일한 사람은 구매하는 사람입니다. NCache 또는 사용 NCache .NET 관점에서. 그래서 그들은 NCache 사내에서 그들은 그것을 Java에 사용하는 것이 좋을 것이라고 말했고 Java 상점은 Java 기반 메모리 내 데이터 그리드를 찾고 .NET 상점은 찾을 것이라고 말했습니다. NCache. 따라서 모든 전문 지식으로 인해 시장이 세분화되는 방식입니다. .NET 상점이라면 Java에 비해 모든 .NET 전문 지식이 있습니다. 그렇다면 왜 그림을 복잡하게 만들까요? 데이터베이스의 경우 SQL이 아닌 데이터베이스에서 모든 데이터베이스를 사용할 수 있습니까? 데이터베이스에 액세스하는 방법은 캐싱 계층에 있는 사용자 지정 코드를 통해 이루어지기 때문에 누구나 가능합니다.
그래서 제가 살펴볼 또 다른 기능은 캐시가 데이터베이스와 동기화 상태를 유지하도록 하는 필수 기능 중 하나는 사용자 지정 코드가 캐시 서버에 있어야 한다는 것입니다. 캐시를 블랙 박스로 만들면 트리거와 저장 프로시저 또는 기타 항목이 없는 관계형 데이터베이스를 갖는 것과 같은 데이터를 제외하고 캐시에는 아무것도 없습니다. 따라서 캐시 사용이 제한됩니다. 그래서 캐시는 단순한 블랙박스로 시작했습니다. Memcached 인기 있는 캐시였고 아무 일도 하지 않았으며 단지 저장소에 불과했고 시간이 지남에 따라 코드를 실행할 수 있는 적절한 지능형 개체로 진화했습니다. 어느 NoSQL, 모든 관계형 데이터베이스를 함께 사용할 수 있습니다. 그리고 다시 말하지만, 제가 말하는 이 모든 기능은 오픈 소스이자 기업용입니다. 그래서 오픈 소스이기 때문에 언급하는 것입니다. 다른 질문? 다룰 때 NCache 대부분 자동 캐싱입니까, 아니면 API를 사용하여 캐싱합니까? 그래서 더 자세히 설명하겠지만 캐싱 대상에 따라 다릅니다. 특정 유형의 캐시 사용은 자동입니다. 예를 들어 ASP를 넣는 경우.NET core 세션은 플러그형 모듈이며 플러그를 꽂고 세션을 캐시에 저장하기 시작하므로 수행해야 할 작업은 없지만 대부분의 이점이 있는 애플리케이션 데이터를 캐시하려는 경우 , 그래서 무엇을 캐싱할지 결정하기 위해 호출해야 하는 API가 있습니까? 얼마나 오래 캐시하시겠습니까? 데이터베이스와 어떻게 동기화하시겠습니까? 당신이 명심해야 할 다른 많은 것들이 있습니다. 따라서 다음과 같은 분산 캐시를 사용하는 방법에 대한 모든 기능을 살펴보겠습니다. NCache 모든 종류의 데이터를 캐시할 수 있지만 API가 있는지 확인합니다. 예.
분산 캐시 사용
좋아요. 이제 분산 캐시가 중요하다는 것을 확인했습니다. 성능과 확장성을 제공합니다. 분산 캐시를 사용하는 방법에 대해 알아보고 사용할 수 있는 세 가지 방법이 있습니다. 세 가지 주요 기술 사용 사례.
앱 데이터 캐싱
첫 번째는 애플리케이션 데이터 캐싱입니다. 지금까지 이야기한 내용이며 이에 대해서는 곧 자세히 설명하겠습니다. 애플리케이션 데이터 캐싱에는 데이터가 데이터베이스와 캐시에 존재한다는 점을 명심해야 합니다. 데이터가 존재하는 곳이 두 군데 있는데, 데이터가 두 곳에 존재할 때 잘못될 수 있는 가장 일반적인 것은 무엇입니까? 그들은 동기화되지 않을 수 있으므로 고객은 캐시에서 한 번, 데이터베이스에서 한 번 은행에서 두 번 그 백만 달러를 인출할 수 있으므로 그런 상황을 원하지 않습니다. 과거에는 상황이 너무 나빠 사람들이 캐시라는 단어를 언급할 때 사용했습니다. 대부분의 사람들은 읽기 전용 데이터를 캐시할 것이라고 생각했습니다. 변경 사항을 캐시하면 잠재적으로 문제가 발생하지 않기 때문에 데이터는 절대 변경되지 않습니다. 따라서 이러한 일이 발생하지 않도록 하는 방법에 대해 알아보겠습니다. 하지만 이는 애플리케이션 데이터 캐싱에서 염두에 두어야 할 가장 중요한 사항입니다.
ASP.NET Core 특정 캐싱
두 번째 사용 사례는 ASP입니다..NET core- 특정 캐싱 및 ASP에서 캐시할 수 있는 두 가지가 있습니다..NET core. 하나는 거의 모든 ASP에 있는 세션입니다..NET core 응용 프로그램은 세션을 사용하고 이전 ASP.NET 환경에서 Microsoft는 InProc, 상태 서버 및 SQL의 세 가지 스토리지 옵션을 제공했으며 네 번째는 사용자 지정이었습니다. 처음 세 개는 실제로 작동하지 않았지만 네 번째는 캐시를 연결할 수 있었지만 ASP.NET core 그들은 실제로 올바른 일을 했습니다. 즉, git 코드에서 가져왔고 실제로 IDistributedCache 인터페이스를 기반으로 설계했습니다. 따라서 타사 상점을 연결할 수 있으며 다음과 같은 것을 연결할 수 있습니다. NCache 자동으로 세션을 저장하기 시작합니다. 그 방법을 보여드리겠습니다.
ASP의 두 번째.NET Core 캐시할 수 있는 페이지 출력인 응답 캐싱입니다. 따라서 다음에 해당 페이지가 호출될 때 페이지가 실행되지 않아야 하며 변경되지 않은 경우 출력을 반환해야 합니다. 동일한 출력을 다시 재생하려는 경우 페이지를 다시 실행하거나 실행하는 이유는 무엇입니까? 단순히 출력을 제공하지 않는 이유는 ASP.NET에서 출력 캐싱이라고 했으며 지금은 응답 캐싱이라고 합니다. 이제 더 많은 HTTP 표준을 기반으로 합니다. 따라서 불가능했던 타사 콘텐츠 캐싱을 에지에 연결할 수 있지만 이에 대해서도 살펴보겠습니다. 응용 프로그램 데이터 캐싱과 ASP의 차이점.NET core 캐싱은 데이터가 존재하는 두 곳이 있는 애플리케이션 데이터 캐싱과 달리 이제 데이터는 캐시에만 존재하고 캐시가 메모리에 있기 때문에 복제가 없는 한 캐시 서버가 다운되면 이 데이터가 손실된다는 것입니다. . 따라서 양호한 복제를 제공하지 않는 캐시는 캐싱 세션 또는 기타 데이터 추세에 적합하지 않다는 점을 명심해야 하는 매우 중요한 사항입니다.
세 번째 ASP가 있습니다..NET core- 실시간 피드백을 제공할 수 있는 라이브 웹 앱이 있는 경우 SignalR이라는 특정 항목에 대해 설명하지 않겠습니다. 주가가 항상 업데이트되어야 한다고 가정해 보겠습니다. 따라서 분산 캐시를 백플레인으로 사용할 수도 있지만 언급하지 않았습니다.
세 큐리
처음 두 가지에 대한 질문이 있으면 필요한 경우 자세히 설명하겠습니다. 따라서 우선 캐시는 애플리케이션 뒤에 있습니다. 애플리케이션과 데이터베이스 사이에 있습니다. 일반적으로 상당히 안전한 환경에서. 애플리케이션이 DMZ에 있는 경우 캐시를 DMZ가 아니라 방화벽 뒤에 유지할 수 있습니다. 때때로 그들은 그것을 DMZ에 보관하지만 대부분의 경우 안전한 상황에 있지만 대형 은행과 같은 많은 금융 서비스 고객은 그것에 만족하지 않기 때문에 더 많은 보안을 원합니다. 따라서 여기에서 Enterprise Edition의 NCache 암호화를 할 수 있는 기능이 있습니다. 따라서 캐시에 넣은 모든 데이터는 3DES 또는 AES256 암호화와 같은 방식으로 자동으로 암호화되며 캐시에 대한 모든 연결이 Active Directory를 통해 인증되고 인증 항목이 있을 것이라는 보안도 있습니다. 따라서 전체 보안 기능이 엔터프라이즈 에디션에 내장되어 있습니다.
일반 고객은 데이터가 민감한 경우가 아니면 암호화를 사용하지 않습니다. 따라서 재무 데이터를 보관하는 경우 일부 규정 준수 문제 또는 HIPAA가 있으므로 규정 준수 문제에 들어가자마자 환경이 안전하더라도 한 단계 더 나아가야 하고 그곳에서 암호화를 수행해야 합니다. . 그래서, NCache Enterprise예를 들어 클라이언트와 캐싱 계층 간의 TLS 연결을 수행합니다. 따라서 연결 자체가 완벽하게 보호되고 암호화 기능이 내장되어 있어 메모리에 보관되는 데이터가 무엇이든 암호화된 형태로 보관됩니다. 그리고 그것은 꽤 많이 만족합니다. 제 말은 우리가 많은 금융 서비스 고객을 보유하고 있으며 그들은 그것에 완전히 만족한다는 것을 의미합니다.
NCache 배포할 수 있으며 대부분의 고객이 여전히 온프레미스 상황에서 사용하고 있습니다. 따라서 애플리케이션이 배포되는 자체 데이터 센터가 있으므로 배포합니다. NCache 그들의 응용 프로그램의 일부로. 당신이 클라우드에 있다면, NCache Azure와 AWS 모두에서 사용할 수 있으며 VM으로 사용할 수 있거나 관리형 캐시 서비스를 막 시작하려고 합니다. NCache 클라우드의 가상 네트워크 내에 있습니다. 따라서 온프레미스에서는 문제가 되지 않습니다. 항상 자신의 환경에서 여러 VM을 얻거나 자체 데이터 센터인 경우 자체 서버를 가져와 애플리케이션과 함께 배포하기 때문입니다. 당신은 설치 NCache 소프트웨어로서 내부 설치를 위한 것이므로 도커를 사용할 수도 있고 최신 응용 프로그램이 할 수 있을 것으로 기대하는 모든 것을 보았습니다. NCache 할 것이다. 그런 다음 클라우드에서 VM을 가져오거나 관리 캐시를 가져올 수 있지만 클라우드에서는 항상 AWS의 경우 VPC 내에서, Azure의 경우 vnet에서 만들 것입니다. 가상 네트워크 내에 있습니다. 따라서 여러 홉에 걸쳐 성장해야 하는 경우가 아니라면 호스트 캐시인 경우 소규모 애플리케이션에는 적합하지만 심각한 경우에는 애플리케이션에 가깝습니다. NCache 해당 응용 프로그램을 통해 비즈니스를 수행하는 미션 크리티컬 응용 프로그램에서 거의 항상 사용됩니다. 그래서, 그것이 당신이 사용할 곳입니다 NCache.
따라서 이러한 상황에서는 속도 저하를 허용할 수 없으며 속도를 저하할 여유가 없는 경우 여기에서 모든 제어를 원하고 캐시를 가능한 한 응용 프로그램에 가깝게 유지해야 합니다. 어떤 사용 사례를 수행할 것인지에 따라 다르므로 예를 들어 가장 크고 빠른 이점은 세션이며 코드 변경 없이 즉시 연결하기만 하면 됩니다. 바로 구성 변경입니다. ASP의 경우.NET core, 구성 변경이 아닙니다. 이것은 시작 파일 코드 변경이지만 매우 작을 뿐이지만 응용 프로그램 데이터 캐싱을 수행하려는 경우 여전히 매우 간단한 변경입니다.
API가 어떻게 생겼는지 빠르게 보여드리겠습니다. 따라서 이 API를 살펴보십시오.
캐시 연결Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");아주 작은 cache.get, cache.add, Insert, remove입니다. 따라서 개체로 키와 값이 있습니다. 따라서 통합하기는 매우 쉽지만 가서 만들어야 하므로 데이터베이스에서 데이터를 가져올 때마다 먼저 캐시를 확인하고 캐시에 있는 경우 캐시에서 가져오거나 그렇지 않으면 데이터베이스로 이동합니다. 그것을 얻고 당신은 그것을 캐시에 넣습니다. 그것이 모델입니다. 정확히. 그렇지 않으면 속도를 높일 것입니다. 성공하지 못할 것입니다. 내가 보여줄게 NCache 조금 후에.
Pub/Sub 메시징 및 이벤트
따라서 게시/구독 메시징도 매우 강력한 기능입니다. 오늘날 많은 애플리케이션은 노력을 조정해야 합니다. 나는 오늘 많은 이벤트 기반 프로그래밍이 필요하다고 말한 누군가와 이야기를 나누었습니다. 따라서 게시/구독 메시징은 매우 강력한 이벤트 기반 프로그래밍 모델을 제공합니다. 이제 애플리케이션 내에서 확장 가능한 메모리 내 플랫폼인 인프라가 있기 때문에 메시징 버스처럼 생각할 수 있습니다. 분산 환경용이 아닙니다. 동일한 데이터 센터의 한 위치 유형의 상황이지만 모두 인메모리이고 확장 가능하기 때문에 매우 빠릅니다. 이것이 다음과 같은 분산 캐시를 사용하는 세 번째 사용 사례입니다. NCache. 예, 그렇습니다. 그리고 오픈 소스도 이를 지원합니다. 따라서 이러한 모든 기능은 오픈 소스와 엔터프라이즈 모두에서 사용할 수 있습니다. NCache API는 오픈 소스와 엔터프라이즈 간에 거의 동일합니다.
우리가 pub/sub에서 본 것은 트래픽이 많은 애플리케이션, 높은 트랜잭션이 있는 경우 pub/sub 엔진이 매우 빨라야 한다는 것입니다. NCache 정말 빛난다.
ASP.NET Core 앱 데이터 캐싱
좋아요. 따라서 애플리케이션 데이터 캐싱입니다. 어떻게 합니까? 그래서 그것은 또한 거기에 대답할 것입니다, 그래서 당신이 그것을 할 수 있는 세 가지 방법이 있습니다.
IDistributedCache
ASP에서 IDistributedCache 인터페이스를 사용할 수 있습니다..NET core 함께 제공되며 이에 대해 프로그래밍한 경우 플러그인할 수 있습니다. NCache 공급자로. 따라서 IDistributedCache API 프로그래밍을 만든 후에는 더 이상 코드를 변경할 필요가 없습니다. 따라서 장점은 한 번 프로그래밍하면 어떤 캐싱 공급업체에 얽매이지 않는다는 것입니다. 단점은 최소 공통 분모라는 것입니다. 그것이 전부인 것처럼 보이는 것을 보여드리겠습니다. Get and Put이 있습니다. Get, Remove 및 Set을 알고 있지만 캐시를 최대한 활용하기 위해 수행할 수 있는 작업이 훨씬 더 많습니다. 우리는 캐시가 데이터베이스와 동기화되기를 원한다는 사실에 대해 이야기했습니다. 따라서 장단점이 있습니다.
Entity Framework Core Cache
두 번째는 EF Core 애플리케이션이 있고 EF Core 애플리케이션이 있는 경우 플러그인하는 더 간단한 방법입니다. NCache 보여드리겠습니다. 따라서 우리는 실제로 EF Core용 확장 메서드를 구현했으며 다시 한 번 이것은 오픈 소스이자 엔터프라이즈입니다. EF Core 샘플이 있습니다. 좋아요. 따라서 EF Core 애플리케이션이 있는 경우 일반적으로 이와 같은 EF Core 쿼리가 있고 LINQ 스타일 쿼리를 사용하여 항목을 가져옵니다. 따라서 우리는 확장 메서드를 구현했습니다. FromCache라고 해봅시다. 메서드는 여러 개이고, 이것도 그 중 하나이므로 이 쿼리가 캐시에 마지막으로 저장된 경우 캐시로 이동하여 다음에서 가져옵니다. 은닉처. 캐시에 없으면 데이터베이스로 이동하여 이 일반 EF 코어 쿼리를 실행하고 가져와서 캐시에 넣습니다. 따라서 데이터베이스에서 오는 모든 데이터를 캐시하기 위해 한 줄 또는 한 메서드 호출이 자동으로 시작됩니다. 따라서 작업을 단순화하고 플러그인할 위치를 정확히 알 수 있으므로 수행해야 하는 추가 API 호출이 많지 않습니다.
따라서 EF 핵심 애플리케이션의 경우에도 코드 변경이 있지만 데이터 캐시를 수행하고 시작할 수 있는 작업은 가능한 한 적습니다. 따라서 실제로 EF 코어의 경우 여러 가지 방법이 있습니다. 이것은 FromCache입니다. 대부분은 FromCache, LoadIntoCache, FromCacheOnly에서 사용할 수 있는 약 XNUMX~XNUMX가지 방법이 있습니다. 따라서 EF Core를 사용하여 변경 사항을 저장하면 데이터베이스를 업데이트하기 전이나 후에 캐시도 업데이트하고 캐시도 업데이트합니다. 따라서 캐시에는 업데이트된 버전의 데이터가 있습니다. 캐시의 무결성은 우선 캐시에 보관하는 모든 데이터를 확인함으로써 유지됩니다. 예를 들어, 이것은 캐시 서버입니다. 두 대의 서버가 있고 세 대의 서버가 있다고 가정해 봅시다. 전체 캐시는 파티션으로 나뉘고 모든 파티션에는 고유한 버킷 세트가 있으므로 데이터는 파티션 중 하나에만 상주합니다. 그런 다음 해당 데이터는 복제본이라고 하는 다른 서버에 복제되지만 다음의 경우에는 복제본이 됩니다. NCache 활성 상태가 아닌 수동 상태이므로 애플리케이션이 복제본과 통신하지 않습니다. 애플리케이션은 파티션과만 통신합니다. 따라서 데이터가 한 위치에만 저장되기 때문에 동기화 문제가 없습니다. 모든 사람이 같은 서버로 이동하지만 분할되어 있기 때문에 모든 사람이 같은 서버로 이동하는 것은 아닙니다. 일부 키는 여기에 저장되고 일부는 여기에 저장되며 일부는 여기에 저장됩니다.
이것이 바로 분산 캐시와 같은 것입니다. NCache 관계형 데이터베이스의 특성상 분할할 수 없기 때문에 SQL 서버가 수행할 수 없는 작업을 수행할 수 있지만 분산 캐시의 특성은 분할할 수 있고 여기에서 분할할 때 서버 XNUMX대이며 XNUMX개의 애플리케이션 서버에서 공유할 수 있습니다. 모든 응용 프로그램 서버에는 XNUMX개, XNUMX개 또는 XNUMX개 또는 XNUMX개의 작업자 프로세스가 있을 수 있습니다. 따라서 캐시와 통신하는 다양한 클라이언트 프로세스가 있으며 실제 데이터가 한 위치에만 저장되기 때문에 동기화 문제가 없습니다. 이제 다른 토폴로지가 있습니다. NCache 동일한 데이터가 활성-활성 및 여러 개 존재하는 경우 복제됩니다. NCache 변경 사항을 동기화해야 합니다. 토큰 기반이고 시퀀스 기반 업데이트 알고리즘이며 확장성이 높지 않습니다. 따라서 트랜잭션이 많은 환경에는 권장하지 않습니다.
복제가 있는 분할된 캐시가 더 나은 전략이거나 사용하기에 더 나은 캐싱 토폴로지라고 합니다. 그래서, 그렇게 NCache 캐시 내에서 데이터가 항상 올바른지 확인합니다. 귀하의 질문에 대한 답변이 되었습니까? 그래서, 당신이 보여준 포트는 그것을 선택해야 하는 캐시에서 말하는 코드에 대한 구성이나 설정이 있습니까? 응. 예를 들어 app.config로 이동하면 mycacheId를 사용한다고 표시되고 캐시가 무엇인지 보여드리겠습니다. 따라서 캐시를 만들 때 NCache. 모든 캐시에는 이름이 있고 장면 뒤에 있는 해당 이름은 캐시가 어디에 있는지 알고 있으므로 여기에서 이름을 지정하기만 하면 어디로 가서 캐시를 가져올지 알 수 있습니다. 캐시가 실제로 어떻게 생겼는지 보여드리겠습니다. 하나의 캐시 이름은 이러한 모든 서버에 있으며 동일한 서버 내에서 여러 캐시 이름을 가질 수 있습니다. 동일한 서버에서 여러 캐시를 가질 수 있으며 하나의 캐시는 여러 서버에 있을 수 있으며 분산 캐시이므로 하나의 캐시 이름이 있어야 합니다. 여러 서버에서 분산되는 방식이지만 다른 캐시 이름에도 동일한 서버를 사용할 수 있으며 각 캐시 이름은 격리됩니다. 좋은 질문.
고 가용성
그래서 고가용성이 정말 정말 중요하다고 말한 것입니다. 중단 없이 런타임에 서버를 추가하거나 제거할 수 없다면 애플리케이션의 가용성이 실제로 높지 않은 것입니다. 운영하고 있는 고객이 있습니다. NCache 중단없이 몇 달, 몇 년 동안. 예를 들어 서버가 XNUMX개인 구성이 있고 로드가 증가하여 방금 세 번째 서버를 추가했다고 가정해 보겠습니다. 따라서 세 번째 서버를 추가해야 합니다. 세 번째 서버를 추가하기만 하면 됩니다. 도구를 통해 보여드리겠습니다. 하나만 추가하면 됩니다. NCache 무대 뒤에서 다시 분할됩니다. 따라서 이 두 파티션은 이제 세 개의 파티션으로 변환됩니다. 여기와 여기의 버킷 중 일부는 애플리케이션이 실행되는 동안 자동으로 세 번째 파티션에 할당되며 애플리케이션은 이를 인식하지도 못합니다. 세 번째 파티션이 존재하고 이제 복제본도 생성된 세 번째 복제본이 있으므로 장면 뒤에서 복제본 2를 여기로 이동해야 하고 복제본 3이 여기에서 생성되었다고 가정해 보겠습니다.
NCache 그것을 유지, 이 뒤에 NCache 해시 매핑에 키를 사용하지만 재분할 및 재할당되는 버킷 맵과 같은 분산 맵과 같이 모든 것을 동적으로 수행합니다. 따라서 데이터는 실제로 런타임에 자동으로 한 서버에서 다른 서버로 이동합니다.
위치 선호도
따라서 경우에 따라 일부 데이터를 동일한 파티션에 함께 보관해야 할 수도 있습니다. NCache 에는 지정할 수 있는 위치 선호도 기능이 있으며 이를 지정합니다. 이 두 데이터 조각이 관련되어 있다고 말할 것입니다. 동일한 서버에 있기를 원합니다. NCache 그 위에 생성하는 추가 키를 통해 동일한 서버에 보관합니다. 내가 말했듯이 그것들은 모두 고급 기능이며 최소 공통 분모로 이동하면 얻을 수 없으며 이러한 기능을 사용하여 조정할 수 있습니다. NCache 특히 귀하의 필요에 따라 귀하의 환경에.
앱 데이터 캐싱 기능
그래서 제가 가장 먼저 다루고 싶었던 주제는 매우 중요합니다. 애플리케이션 데이터 캐싱의 경우 가장 중요한 것은 캐시가 항상 신선하다는 것입니다. 즉, 신선하다는 것은 올바른 데이터를 가지고 있음을 의미하며, 데이터베이스에서 데이터가 변경되면 캐시에 최신 데이터가 있다는 것입니다.
시간 기반 만료
따라서 만료는 캐시가 수행하는 가장 일반적인 방법이며 거의 모든 캐시에는 기능으로 만료가 있습니다. NCache 또한 가지고 있습니다. 절대 만료가 있고 슬라이딩 만료가 있습니다. 절대 만료란, 캐시에 데이터를 추가한다고 가정해 봅시다. XNUMX분 이상 캐시에 데이터를 보관하는 것이 안전하지 않다고 생각하기 때문에 XNUMX분 후에 만료한다고 말할 수 있습니다. 따라서 데이터를 캐시에 XNUMX분 동안 보관하는 것이 안전하고 일부 데이터에는 충분하지만 그렇지 않을 수 있는 데이터에 대해 교육적으로 추측하고 있습니다.
슬라이딩 만료는 세션을 저장하고 아무도 사용하지 않은 후에 괜찮다고 말하는 경우에 더 적합합니다. 모든 사람이 해당 세션 사용을 마친 후에는 그냥 제거하십시오. 따라서 정리 만료에 가깝습니다. 절대 만료는 동기화이며 데이터베이스와 일관성을 유지하는 것입니다. 슬라이딩은 정리되지만 만료는 추측이 잘못되었든 교육받은 추측입니다.
데이터베이스 종속성
어떤 경우에는 데이터가 일관성이 없어도 되지만 그렇지 않은 경우도 있습니다. 따라서 할 수 없다면 다른 기능이 있어야 합니다. NCache 예를 들어 데이터베이스와 캐시를 동기화할 수 있다는 점이 정말 두드러집니다. 그래서, NCache SQL Server에 내장된 SQL 종속성을 사용하여 SQL Server를 모니터링합니다. 따라서 캐시하는 모든 항목에 대해 SQL 데이터베이스 테이블의 해당 행과 ok 매핑을 말할 수 있습니다. NCache 해당 행이 변경되면 모니터링합니다. NCache 그런 다음 캐시에서 해당 항목을 제거하거나 다시 로드합니다. 이제 갑자기 인텔리전트 캐시가 생겼고, 캐싱하는 것이 무엇이든 항상 일관성을 유지할 수 있으며 이는 캐시가 블랙박스인 경우 얻을 수 없는 것입니다.
따라서 캐시를 통해 이러한 유형의 인텔리전스를 보유할 수 있어야 하며 SQL 종속성은 .NET 기능이므로 여기에서 NCache 데이터베이스가 SQL인 경우 .NET이 도움이 됩니다. 이제 우리는 또한 Oracle 데이터베이스 알림을 사용하는 Oracle 종속성이며 이를 수행하는 또 다른 방법은 폴링 기반 알림입니다. 이 알림은 더 효율적이지만 실시간은 아니므로 다음과 캐시를 동기화할 수도 있습니다. 비관계형 데이터 소스. 귀하의 데이터는 NoSQL database, 클라우드에 있을 수도 있고 어디에나 있을 수도 있고 모니터링할 수 있기를 원할 수도 있습니다. 따라서 캐시 서버에 있는 코드인 사용자 지정 종속성을 만들 수 있습니다. NCache 일정 간격으로 호출하면 데이터 소스를 확인하고 데이터가 변경되면 알려줍니다. NCache, ok 데이터가 변경되었습니다. 이것을 제거하거나 다시 로드하십시오.
그래서 이 지역은 NCache 정말 정말 강합니다. 데이터를 최신 상태로 유지하려면 캐시가 최신 상태인지 확인하기 위해 다음 작업을 수행할 수 있어야 합니다.
읽기 및 쓰기
또 다른 기능은 read-through 및 write-through입니다. 이제 이것은 만료 및 데이터베이스 동기화와 결합됩니다. 이렇게 하면 캐시가 데이터베이스에서 데이터를 로드할 수 있습니다. 예를 들어 읽기가 있는 경우 읽기가 어떻게 보이는지 보여 드리겠습니다. 구현하는 인터페이스일 뿐이고 코드는 실제로 캐시에 있으므로 이 코드를 구현하는 인터페이스는 다음과 같습니다. 따라서 소스 호출에서 부하가 발생하여 키를 제공한 다음 NCache 메서드를 호출하고, 캐시 서버가 메서드를 호출하고, 이 코드가 서버, 모든 캐시 서버에서 실행 중입니다. NCache 이 메서드를 호출하고 이 키가 캐시에 없기 때문에 이 키를 로드하십시오. 따라서 캐시를 수행하면 키가 캐시에 없다고 생각하고 키가 존재하지 않는다고 null을 반환하거나 read-through가 있는 경우 캐시로 이동할 수 있습니다. 그리고 NCache 데이터베이스로 이동하여 읽을 수 있습니다. 그래서, 당신은 항상 그것을 가질 것입니다. 이것은 항상 캐시에 데이터를 보관하려는 많은 경우에 매우 유용합니다.
따라서 읽기를 통해 읽기를 만료 또는 데이터베이스 동기화와 결합할 때 데이터가 만료될 때 수행할 수 있습니다. NCache 자동으로 새로 고칠 수 있습니다. 왜 제거합니까? 데이터를 새로고침하려는 경우 어쨌든 해당 데이터가 필요하고 최신 상태로 유지하기 위해 만료되기 때문에 다음에 다시 로드해야 합니다. 그래서, 왜 그냥 NCache 돌아가서 다시 로드하십시오. read-through를 구현한 경우, NCache 데이터베이스 또는 데이터 소스의 데이터가 변경되고 이 동기화 기능이 해당 데이터베이스가 변경되었음을 확인하면 동일한 작업이 자동으로 수행되며 읽기를 구현한 경우 자동으로 이동하여 다시 로드합니다. .
마찬가지로 write-through는 write-behind가 있는 경우 캐시를 업데이트할 수 있다는 또 다른 이점을 제공합니다. 따라서 일부 데이터는 업데이트에 그다지 민감하지 않습니다. 물론 재무 데이터 은행 잔고라면 쓰기를 원하지 않지만 어떤 경우에는 업데이트를 대기열에 추가할 수 있으면 괜찮습니다. 따라서 캐시를 업데이트하면 캐시를 업데이트하는 것이 데이터베이스를 업데이트하는 것보다 훨씬 빠릅니다. 물론 캐시가 분산되어 있고 캐시를 업데이트하고 NCache 계속해서 데이터베이스를 뒤에서 비동기식으로 업데이트하십시오. 이것이 바로 write-behind 기능이고 병목 현상이 발생하기 때문에 갑자기 응용 프로그램 속도가 빨라집니다. 데이터베이스에서 읽고 데이터베이스에 씁니다. 읽기를 캐시할 수 있으므로 데이터베이스로 이동하지 않아도 쓰기 작업은 데이터베이스로 이동해야 합니다. 데이터베이스가 마스터라는 의미일 수는 없습니다. 쉽습니다.
그래서 또 다른 기능이 있다면 NCache 갑자기 응용 프로그램을 더욱 향상시킬 수 있습니다. 질문: 만약을 대비하여 데이터베이스에 쓸 수 없고 비동기를 수행하면 예외가 발생합니까? 예. 예외가 발생합니다. 다음에 의해 호출되는 콜백을 가질 수 있습니다. NCache 코드는 이 write-behind 코드가 캐시 서버에서 실행 중이지만 콜백이 여기에 있으므로 클라이언트에 다시 알리고 콜백이 호출되므로 수정 작업을 수행할 수 있습니다. 캐시에 익숙해지면 NCache 캐시를 데이터베이스와 동기화할 수 있으므로 점점 더 많은 데이터를 캐시하게 됩니다. 더 많은 데이터를 캐시할수록 더 많은 캐시가 데이터베이스처럼 보이기 시작합니다. 즉, 데이터를 가져오는 키-값 방식이 충분히 똑똑하지 않다는 의미입니다. 따라서 SQL 기반의 데이터, 특히 참조 데이터를 찾을 수 있어야 합니다.
SQL 검색
키뿐만 아니라 특성을 기반으로 데이터를 가져오는 EF Core 쿼리에 대해 이야기했을 때. 따라서 SQL 또는 LINQ 쿼리 또는 캐시를 훨씬 빠르게 만드는 EF 코어를 사용하여 데이터를 검색할 수 있는 경우. 그건 또 다른 방법이야 NCache 눈에 띄는 점은 모든 데이터를 캐시에 넣으면 검색할 수 있고 보스턴이나 뉴욕에 기반을 둔 모든 고객을 제공할 수 있으며 캐시에서 고객 개체 모음을 제공한다는 것입니다. 따라서 데이터베이스처럼 보이기 시작하고 특히 참조 데이터에 대한 데이터베이스의 모든 부담을 덜 수 있습니다. 따라서 SQL 검색은 정말 정말 중요합니다.
좋아요. 이제 무엇을 보여주고 싶다 NCache 어떤 캐시처럼 보이나요? 그래서 저는 Azure에 로그인했습니다. 따라서 두 개의 캐시 서버 VM이 있습니다. 따라서 두 개의 캐시 서버, 하나의 Windows 클라이언트 및 하나의 Linux 라인이 있습니다. .NET Core, Windows 또는 Linux에서 응용 프로그램을 실행할 수 있으며 NCache 실제로 캐시 서버는 다음으로 인해 Linux에서 실행될 수 있습니다. .NET Core 때문에 NCache 이다 .NET Core 원주민.
캐시 생성
예를 들어 저는 Windows 클라이언트에 원격 데스크톱을 수행했습니다. 실제로 캐시를 생성할 것이므로 캐시에는 두 개의 서버가 있고 하나의 Windows 클라이언트와 하나의 Linux 클라이언트가 있습니다. 클라이언트라는 단어를 사용할 때 실제로는 애플리케이션 서버 상자입니다. 좋아요. 그래서, 나는 이것을 사용할 것입니다 NCache 관리자 도구. 이제 이 도구는 Enterprise Edition의 일부이지만 오픈 소스 명령줄 도구 또는 구성 파일을 통해 모든 동일한 작업을 수행할 수 있지만 편의상 캐시를 생성하겠습니다.
모든 캐시에 이름이 있다고 말했듯이 내 캐시 데모 캐시라고 부를 것입니다.
토폴로지를 선택하겠습니다. 복제가 있는 분할된 캐시를 선택하겠습니다.
비동기 복제를 할 테니 비동기 복제와 비동기 복제가 있습니다. 동기화 복제는 더 민감한 데이터, 금융 데이터 및 이러한 복제가 업데이트의 일부로 발생하기를 원하는 경우 비동기를 수행할 여력이 없는 경우입니다. 물론 속도는 느려지지만 속도는 더 빨라집니다.
여기 제 캐시 서버 6이 있고 여기 제 캐시 서버 7가 있습니다. 이제 막 XNUMX서버 클러스터를 만들었습니다. 아직 실행되지 않습니다. 두 개의 클라이언트 노드를 추가하겠습니다. 이것은 내 창문이고 서버가 있었습니다. 따라서 XNUMX은 내 Windows 클라이언트이고 XNUMX은 내 UNIX 클라이언트입니다. 좋아요. 그래서 저는 일반적으로 XNUMX개의 캐시 서버와 XNUMX개의 클라이언트를 가지고 있습니다. 앞서 말했듯이 최소 XNUMX개의 캐시 서버와 XNUMX:XNUMX, 클라이언트와 서버 사이의 비율은 XNUMX:XNUMX입니다. 그래서 지금 막 캐시를 시작하고 있습니다. 다시 말하지만, 한 곳에서 이 모든 작업을 수행할 수 있으며 막 출시할 다음 버전에서도 동일하게 수행할 수 있습니다. 이것은 모두 웹 기반이므로 클라우드에서 바로 수행할 수 있습니다. 통계를 열겠습니다. 모니터링과 같은 perfmon 통계입니다.
스트레스 시뮬레이션 및 캐시 통계 모니터링
내 클라이언트가 이것과 대화할 수 있는지 테스트하고 볼 것입니다. 이제 이 상자는 클라이언트입니다. 이제 PowerShell 콘솔을 열겠습니다. Windows에서 두 개의 부분을 가져오고 여기에 두 개의 Linux에 로그인했습니다. 따라서 여기에 Linux가 있고 이제 여기에 Linux가 있습니다. 오른쪽? 여기에서 PowerShell을 시작해야 하고 여기에서 Windows용으로 수행할 필요가 없는 내 모듈도 가져와야 합니다. 모듈은 이미 존재하며 여기에서도 동일한 작업을 수행해야 합니다. Linux에서 PowerShell을 시작해야 합니다. 이제 클라이언트를 시작하겠습니다. 그래서, NCache 이 스트레스 테스트 도구와 함께 제공되므로 자신의 환경에서 스트레스 테스트를 정말 쉽게 할 수 있습니다. 그래서, 당신이 정확히 어떻게 볼 수 있도록 NCache 공연? 따라서 성능에 대해 한 마디도 할 필요가 없습니다. 예를 들어 서버당 초당 약 500개의 요청을 처리한다고 가정해 보겠습니다.
좋아요. 그래서 부하를 높이고 싶어서 XNUMX차 콘솔로 가서 스트레스 테스트를 다시 실행하라고 합니다.
자, 갑자기 여러분은 이것이 두 배로 뛰는 것을 보게 될 것입니다. 그리고 제가 계속해서 스트레스를 더 추가하겠습니다. 나는 Linux 중 하나에 와서 같은 말을 할 것이고 갑자기 지금은 요청 당 1500과 비슷합니다. 이제 저는 초당 총 약 3,000개의 요청을 처리하고 있습니다. 예를 들어 다른 작업을 수행하겠습니다. 지금은 초당 4,000개 이상의 요청을 처리하고 있습니다. 따라서 더 많은 VM이 있으면 계속해서 더 추가할 수 있습니다. 더 많은 인스턴스를 가질 수 있습니다. 곧 보게 될 것입니다. 이것이 무엇이든 간에 최대값에 도달하고 이 두 서버는 초당 최소 50,000건의 요청을 처리할 수 있습니다. 하지만 개체 크기가 증가함에 따라 당연히 감소하겠지만 작은 데이터 세트를 사용하는 경우입니다. 제대로 실행하면 세 번째 VM이 없지만 이 작업을 수행하고 세 번째 주소를 추가하기만 하면 됩니다. 완료라고 말하면 여기에 세 번째 상자가 추가되고 모든 분할이 수행됩니다. 또는 자동으로 다시 분할합니다.
마찬가지로 VM을 중단해야 하는 경우에도 그렇게 할 것입니다. 그래, 그게 내 얘기의 끝이야. 질문에 답변해 드릴까요? 유일한 기본 .NET 솔루션이며 다른 유일한 기본 솔루션은 AppFabric 중단된 것. 그래서, Redis .NET 솔루션은 아니지만 Microsoft는 기술에 구애받지 않기를 원했기 때문에 Azure용으로 선택했습니다. 그래서 선택했지만 기본 .NET입니다. 우리는 처음부터 그렇게 해 왔으며 우리가 아는 한 .NET에서 가장 선호하는 선택입니다.