XNUMX가지 ASP.NET 성능 부스터
녹화된 웨비나
Ron Hussain 및 Nick Zulfiqar 작성
분산 .NET 캐시를 사용하여 ASP.NET 성능과 확장성을 높이는 방법을 알아보십시오. 이 웨비나를 시청하여 ASP.NET 응용 프로그램의 확장성을 위해 ASP.NET 성능을 높이는 XNUMX가지 방법과 메모리 내 분산 캐시를 사용하여 이를 효과적으로 해결하는 방법에 대해 알아보십시오.
수석 솔루션 아키텍트와 지역 영업 이사가 공동으로 제공하는 다음 사항에 대해 알아보십시오.
- ASP.NET 응용 프로그램 데이터 캐싱
- ASP.NET 세션 상태 캐싱
- ASP.NET SignalR Backplane 분산 캐시 사용
- ASP.NET View State 캐싱
- ASP.NET 출력 캐싱
오늘 우리는 ASP.NET 응용 프로그램 성능과 확장성을 향상시키는 5가지 방법에 대해 이야기할 것입니다. 그것은 매우 뜨거운 주제입니다. 수요가 많은 것입니다. 그래서, 우리는 당신을 위해 이것을 가져 기쁘게 생각합니다. Ron은 잠시 후에 이에 대해 이야기할 것입니다. 또한 이 프레젠테이션 중에 질문이 있는 경우 비디오에 자유롭게 입력해 주시면 Ron의 주의를 끌 수 있도록 하겠습니다.
그래서, 론 어떻게 시작합니까? 고마워, 닉. 안녕하세요 여러분, 제 이름은 Ron이고 오늘 웨비나의 발표자가 될 것입니다. Nick이 제안한 것처럼 오늘 우리가 선택한 주제는 XNUMX가지 ASP.NET 성능 부스터입니다. 그래서 우리는 다섯 가지 다른 기능에 대해 알아볼 것입니다. 처음에는 ASP.NET 웹 응용 프로그램에서 일반적으로 볼 수 있는 다섯 가지 문제에 대해 이야기하겠습니다. 이러한 문제는 실제로 응용 프로그램의 속도를 늦추고 성능을 저하시키는 일상적인 문제이며 확장성은 또 다른 방법입니다. 우리는 이러한 병목 현상에 대해 이야기한 다음 분산 캐싱 시스템의 도움으로 다른 솔루션에 대해 이야기할 것입니다. ASP.NET 응용 프로그램 내에서 이러한 문제를 해결하는 방법은 무엇입니까? 이것이 오늘 우리가 준비한 것입니다. 다양한 기능을 다루고 샘플 응용 프로그램을 가지고 있으며 이것을 설정하고 시작하는 방법에 대한 모든 것을 실제로 보여 드리겠습니다. 그래서, 꽤 인터랙티브한 실습 웨비나가 될 것입니다. Nick이 언급했듯이 질문이 있는 경우 주저하지 말고 참여해 주세요. 그 모든 질문에 기꺼이 답변해 드리겠습니다. 좋아, 모든 것이 좋아 보인다고 가정하고 이것부터 시작하겠습니다.
ASP.NET은 트래픽이 많은 웹 앱에 널리 사용됩니다.
그래서 우선 ASP.NET 플랫폼 전반에 대해 이야기하겠습니다. ASP.NET은 웹 응용 프로그램을 위한 매우 인기 있는 플랫폼입니다. 우리는 많은 웹 배포를 보고 있으며 인기가 높아지고 있습니다. ASP.NET 플랫폼의 좋은 점은 사용 패턴을 기반으로 하므로 꽤 멋지게 확장되며 수천 명의 동시 사용자와 관련 요청을 애플리케이션 아키텍처 내에서 변경하지 않고도 처리할 수 있다는 것입니다. 웹 팜을 생성할 수 있고, 웹 가든을 생성할 수 있으며, 많은 확장성 옵션을 제공하고, 로드 밸런서를 앞에 놓고 다른 웹 서버 간에 요청을 라우팅할 수 있으며 선형 확장성, 수평 확장성을 달성할 수 있습니다. ASP.NET 웹 팜에서.
로드 밸런서는 웹 서버 또는 앱 서버의 상태 저장 특성에 따라 아키텍처에 따라 고정 로드 밸런싱 또는 균등 로드 밸런싱을 가질 수 있으며 필요에 따라 확장할 수 있습니다.
따라서 이것은 ASP.NET 응용 프로그램을 위한 일반적인 웹 팜 배포입니다. 웹 팜 내에서 웹 서버를 설정하기 위해 로드 밸런서를 통과하는 N개의 클라이언트가 있고 그런 다음 한 종류의 데이터인 ASP.NET 세션 저장소가 있습니다. ASP.NET 웹 응용 프로그램 내에서 볼 수 있습니다. 그런 다음 데이터베이스 서버, 관계형 데이터베이스 또는 NoSQL database■ 많은 양의 데이터를 앞뒤로 처리할 수 있으며 애플리케이션이 상호 작용하는 다른 백엔드 데이터 시스템 메인프레임 파일 시스템이 될 수 있습니다. 따라서 이것은 꽤 대중적이고 확장 가능하며 매우 빠르며 많은 활성 배포에서 이 플랫폼을 사용하고 있습니다.
문제: 확장성 병목 현상
이제 ASP.NET 내의 확장성 병목 현상에 대해 이야기해 보겠습니다. 정확히 어디에 문제가 있습니까? 그것은 확장성 문제를 매우 훌륭하게 확장하는 것입니다. 확장성이 무엇인지 빠르게 정의해 봅시다. 확장성은 애플리케이션 아키텍처 또는 애플리케이션이 배포된 환경 내의 기능입니다. 성능 저하 없이 초당 요청 수 또는 주어진 요청, 동시 요청 수를 늘릴 수 있는 기능입니다. 사용자가 5000명 미만인 경우 특정 지연 시간이 있습니다. 그 대기 시간을 유지하는 것은 어떻습니까? 성능을 저하시키지 않고 성능을 향상시키지 않아도 괜찮지만 최소한 500,000명의 사용자 또는 XNUMX명의 사용자 미만의 성능을 유지하는 것입니다. 그 능력 자체를 확장성이라고 합니다. 여기서 시스템에서 최대 처리량을 얻을 수 있고 점점 더 많은 요청 로드가 발생합니다. 처리된 다음 사용자 로드가 증가해도 대기 시간이 증가하지 않습니다. 따라서 본질적으로 극한 부하에서의 성능 또는 극한 부하에서의 극한 성능입니다. 그래서 그 능력을 확장성이라고 합니다.
이제 일반적으로 ASP.NET 응용 프로그램은 웹 팜이 매우 확장 가능하지만 이제 웹 팜 내에서 확장성 문제를 제공하지만 주로 백엔드 데이터 원본으로 인해 최대 부하에서 속도가 느려질 수 있습니다. 따라서 애플리케이션 속도가 느려지면 엄청난 양의 로드로 인해 질식되고 해당 애플리케이션은 확장성 후보이므로 자체적으로 확장 가능한 아키텍처가 필요합니다. 애플리케이션이 당신의 세계를 느낄 수 있는 이유 또는 애플리케이션이 최대 부하에서 느려지는 이와 같은 상황을 보게 되는 이유, 애플리케이션 내에서 다른 데이터 스토리지 정격 병목 현상 또는 일부 병목 현상이 있을 수 있습니다. 따라서 이 시점부터 확장성 기능을 제한하고 확장을 제한하는 ASP.NET 응용 프로그램 내의 다섯 가지 병목 현상에 대해 설명합니다.
두 가지 데이터 스토리지 병목 현상
괜찮은. 따라서 우선 두 가지 데이터 스토리지 병목 현상이 있습니다.
데이터베이스는 확장할 수 없습니다.
일반적으로 확장할 수 없는 응용 프로그램 데이터베이스가 있습니다. SQL Server, oracle 또는 기타 널리 사용되는 관계형 데이터 소스 형태의 관계형 데이터베이스가 있습니다. 저장용으로는 매우 좋지만 엄청난 양의 트랜잭션 로드를 처리할 때는 그다지 좋지 않습니다. 질식하는 경향이 있으며 어떤 경우에는 실제로 시간 초과 오류가 발생합니다. 따라서 최소한 실제로 성능이 저하되므로 즉시 데이터베이스 서버를 추가할 수 없으므로 단일 소스가 됩니다. 복제가 없는 경우에는 단일 실패 지점이기도 합니다. 가장 중요한 문제는 여기에서 가장 중요한 문제는 속도가 매우 빠르지 않고 일반적인 시나리오에서는 느리고 최대 로드에서는 느리고 실제로는 다음과 같은 상황이 악화된다는 것입니다. 증가된 부하를 수용할 수 없으며 작업 속도가 더욱 느려집니다. 이것이 우리의 첫 번째 병목 현상입니다.
ASP.NET 세션 상태 저장소
두 번째 병목 현상은 ASP.NET 세션 상태 저장소와 관련되어 있습니다. 이제 세션 상태는 매우 중요한 종류의 데이터입니다. 사용자 정보가 있는 것입니다. 예를 들어 사용자 정보를 유지 관리하는 전자 상거래 응용 프로그램이나 해당 문제에 대한 장바구니가 있을 수 있습니다. 예약 시스템이 될 수도 있고 발권 시스템이 될 수도 있고 금융 시스템이 될 수도 있습니다. 따라서 사용자가 로그인하고 이 세션 개체 내에서 매우 중요한 데이터를 가지고 있는 모든 종류의 전면 시스템이 될 수 있습니다.
이제 이것들은 ASP.NET 플랫폼이 제공하는 세 가지 모드입니다. 모든 것이 작업자 프로세스 내부에 저장되는 InProc가 있습니다. 따라서 모든 것이 응용 프로그램 프로세스 내부에 있으므로 작업자 프로세스는 상태 비저장이 아니며 HTTP 프로토콜 자체는 상태 비저장이지만 이 경우 작업자 프로세스는 모든 사용자 데이터를 자체적으로 호스팅합니다. 그런 다음 두 번째 옵션인 StateServer가 있고 SQL Server가 있습니다. 따라서 이러한 기존 세션 상태 저장 옵션에 대해 이야기하고 병목 현상에 대해 이야기해 보겠습니다.
우선 InProc은 메모리에 있기 때문에 빠르며 직렬화 역직렬화가 없지만 우선 웹 가든 시나리오를 처리할 수 없다는 단점이 있습니다. 하나의 웹 서버에서는 주어진 애플리케이션에 대해 단일 작업자 프로세스만 있을 것입니다. 왜냐하면 다음 요청이 다른 작업자 프로세스로 이동하는 경우 세션 데이터가 있는 곳이기 때문입니다. 더 이상 해당 세션 데이터가 없으므로 동일한 작업자 프로세스여야 하고 이것이 당신을 제한하는 이유입니다. 기술적으로 InProc 세션 관리로 웹 가든을 실행할 수 없으므로 여기에서 한 가지 제한 요소가 있습니다.
둘째, 로드 밸런서에서 고정 세션 비트를 활성화해야 합니다. 따라서 우선 웹 서버의 성능이나 확장성 또는 리소스를 제한하고 응용 프로그램에 대해 단일 프로세스만 사용합니다. 둘째, 초기 요청이 제공된 웹 서버에서 후속 요청은 항상 동일한 서버로 이동합니다. 그것은 모두 고정 세션 로드 밸런싱 작업이며 작업을 완료하지만 이것의 주요 문제는 한 웹 서버에 많은 사용자가 활성화되어 있지만 다른 웹 서버는 해당 사용자가 이미 로그아웃되어 유휴 상태에 있을 수 있다는 것입니다. 사용자는 본질적으로 끈적 거리기 때문에이 무료 서버에 절대 가지 않을 것이며 항상 데이터가 존재하는 동일한 서버로 이동합니다. 따라서 InProc을 사용하여 고정 세션 로드 밸런싱을 수행해야 하는 또 다른 문제입니다. 가장 중요한 것은 작업자 프로세스가 재활용되고 우리의 경험에 따르면 ASP.NET 작업자 프로세스가 상당히 많이 재활용되는 것을 보았을 때 모든 것을 잃게 된다는 것입니다. 데이터 권리, 유지 관리 관련 작업인 경우 서버가 다운되어야 하는 경우 한 웹 서버를 다운시켜야 하며 다른 웹 서버를 가져와야 하므로 그 결과 모든 데이터가 손실됩니다. 따라서 ASP.NET을 사용한 InProc 세션 관리에서 볼 수 있는 모든 문제, 모든 병목 현상이 요약됩니다. 따라서 이는 분명히 옵션이 아니며 확장성이 매우 좋지 않습니다. 서버 한 대에 해당 서버의 용량에 도달하고 고정이 있는 로드 밸런싱은 실제로 도움이 되지 않습니다.
두 번째 옵션은 StateServer입니다. 상태 서비스 내부의 애플리케이션 프로세스에서 데이터를 가져오기 때문에 InProc보다 약간 낫습니다. 원격 상자 또는 웹 서버 중 하나일 수 있습니다. 전적으로 사용자에게 달려 있지만 문제는 그렇지 않다는 것입니다. 확장 가능하고 단일 소스이므로 해당 서버에서 확장할 수 있지만 수평 확장은 옵션이 아닙니다. 항상 단일 서버, 모든 세션 데이터를 호스팅하는 하나의 서비스가 될 것이며 모든 요청 로드도 관리할 것입니다. 요청 로드가 증가하면 리소스를 추가할 수 있는 옵션이 없습니다. 따라서 상대적으로 확장되지 않을 것입니다. 예를 들어 수백 수천 명의 사용자가 있고 관련 요청이 초당 또는 요청자당 수백만 건의 요청을 생성하거나 수백만 건의 로드가 발생하는 경우와 같이 결국 상태 서비스가 질식할 수 있습니다. . 따라서 해당 StateServer를 기반으로 하면 확장되지 않고 증가하는 부하에 대처할 수 없으며 단일 실패 지점이기도 합니다. StateServer 자체가 다운되면 모든 세션 데이터가 손실되고 세션 데이터는 사용자가 무언가를 구매하려고 하거나 결정을 내리려고 하는 동안 세션을 잃고 싶지 않은 매우 중요한 종류의 데이터이며 영향을 미칠 것입니다. 그 대가로 사업.
세 번째 옵션은 SQL Server입니다. SQL Server는 다시 프로세스 세션 관리가 아니지만 느리고 확장 가능하지 않으며 SQL Server를 더 추가할 수 없으며 트랜잭션 데이터만 처리하기 위한 것이 아닙니다. 응용 프로그램 데이터베이스에서 이 문제는 세션 캐싱뿐만 아니라 데이터 캐싱에서도 동일하게 유지됩니다. 따라서 세션 상태는 ASP.NET 플랫폼이 제공하는 기본 옵션으로 최적화되는 것이 아니며 이는 주로 InProc, StateServer 및 SQL Server를 제공하는 데이터 소스 때문입니다.
이것이 병목 현상에 대한 몇 가지 기본 세부 사항을 구축했기를 바랍니다. 물론 솔루션에 대해 이야기하고 분산 캐싱과 그 기능을 비교하고 이러한 문제를 하나씩 처리하는 방법에 대해 이야기할 것입니다. , 그래서 먼저 모든 문제를 나열한 다음 해결책에 대해 하나씩 이야기하겠습니다. 이 다이어그램은 동일한 것을 보여줍니다.
데이터 저장소 병목 현상 데이터베이스가 있고 세션 관리자로 ASP.NET 세션 저장소 또는 InProc 또는 데이터베이스가 있으며 대부분의 경우 단일 소스가 있는 병목 현상이 있습니다. 매우 안정적이며 일반적으로 느립니다.
ASP.NET View State 병목
이제 세 번째로 중요한 병목 현상은 ASP.NET view state. ASP.NET 웹 팜의 경우 보기 상태가 있습니다. 이제 보기 상태가 무엇인지 알고 싶으신가요? 나는 모두가 알고 있다고 확신하지만 보기 상태는 클라이언트 측 상태 관리이고, 패킷이고, 웹 팜에 있는 제어 위젯의 상태이며, 서버 측에서 구성되고 사용자의 일부가 됩니다. 응답 패킷은 저장된 위치의 브라우저로 돌아가고 브라우저 측에서는 실제로 사용되지 않으며 분산된 요청 패킷의 일부로 해당 페이지에 다시 게시할 때 서버로 다시 가져옵니다. 따라서 요청 및 응답 패킷과 함께 번들로 제공되고 브라우저로 돌아가서 실제로 사용되지 않으며 보기 상태에 대한 한 가지 긴급한 문제는 일반적으로 매우 무겁다는 것입니다. 크기가 수백 킬로바이트이고 트랜잭션 로드가 많고 수백만 개의 트랜잭션이 있는 시나리오를 생각하면 각 트랜잭션에 보기 상태 패킷 번들 또는 ASP.NET 웹 응용 프로그램에 대한 요청 응답 패킷이 있습니다. 보기 상태의 일부이고 요청당 수백 킬로바이트의 보기 상태가 있고 수백만 건의 트랜잭션이 있는 경우 많은 대역폭을 소비하고 일반적으로 페이지 응답 속도가 느려집니다. 앞뒤로 많은 데이터가 있고 그 데이터의 크기도 무거워집니다.
따라서 이는 대역폭을 소모하는 또 다른 병목 현상입니다. 원인이 크게 증가한 다음 보기 상태가 일반적으로 무겁기 때문에 페이지 응답 시간이 느려지고 응답 요청에 대해 더 많은 페이로드를 처리하게 됩니다. 따라서 이것은 ASP.NET 웹 팜의 일부인 또 다른 종류의 병목 현상입니다. ASP.NET 웹 팜 응용 프로그램이 있는 경우 이 문제에서 벗어날 수 없습니다. 기본적으로 많은 보기 상태를 처리해야 하며 이 다이어그램은 보기 상태가 브라우저로 돌아가는 위치를 다루고 있습니다. 클라이언트 측 상태 관리는 서버 측에서 구성되고 브라우저로 돌아가서 가져옵니다. 포스트백에 있는 서버로 돌아갑니다. 이제 요청 및 응답 패킷이 무거워지고 많은 대역폭을 차지하며 페이로드가 많아 속도가 느려집니다.
추가 페이지 실행 병목 현상
이제 네 번째 병목 현상이 있고 두 번째 병목 현상이 있습니다. 추가 페이지 실행 병목 현상 이후에 병목 현상이 하나 더 있습니다. 이제 이것은 ASP.NET 웹 팜과 ASP.NET MVC 웹 응용 프로그램에 적용됩니다. 전체 페이지 출력이 같거나 동적 페이지 내의 일부가 동일한 시나리오가 있으므로 응용 프로그램 내에서 정적 콘텐츠를 매우 자주 처리하게 됩니다. 따라서 페이지 출력은 자주 변경되지 않지만 여전히 해당 요청을 실행하고 있습니다. 요청이 있을 수 있으며 여기에는 렌더링되는 일부 백엔드 데이터베이스가 포함된 다음 백엔드 데이터 소스에서 일부 데이터를 가져오고 해당 데이터를 읽고 의미 있게 만들고 일부 일일 비즈니스 논리 계층, 데이터 액세스 계층을 모두 적용합니다. 좋은 물건을 만들고 그 후에 응답을 렌더링하면 응답이 브라우저의 최종 사용자에게 다시 전송됩니다. 이제 동일한 주기가 다시 진행되어야 하고 내용이 변경되지 않더라도 동일한 주기를 반복해서 거쳐야 합니다. 이 페이지는 변경 여부에 관계없이 실행됩니다. 기본적으로 많은 정적 콘텐츠를 처리하고 콘텐츠가 변경되지는 않지만 여전히 동일한 요청을 실행하고 있습니다. 이제 이는 인프라 비용, 추가 CPU, 추가 메모리, 추가 데이터베이스 리소스를 증가시켜 웹 서버의 용량에 도달할 수 있으며 일반적으로 데이터베이스 사이트의 용량에 도달할 수도 있습니다. 이미 실행된 것입니다. 이것은 또 다른 병목 현상이며 페이지 출력 캐싱을 사용하여 이 문제를 처리하는 방법에 대해 설명합니다. 따라서 이것은 네 번째 병목 현상과 다섯 번째 병목 현상을 다룹니다. 그런데 이 다이어그램은 정적 출력에 대한 페이지 실행을 포함하고 많은 요청을 처리하는 더 많은 데이터베이스를 만듭니다.
ASP.NET SignalR Backplane 병목
그리고 다섯 번째 병목 현상은 SignalR backplane. 이제 이것은 SignalR이 있을 수도 있고 없을 수도 있는 매우 구체적인 사용 사례입니다. 그러나 SignalR에 익숙하고 백플레인을 설정했다면 백플레인은 공통 메시지 버스이고 웹 서버는 모든 메시지를 전송합니다. 클라이언트 브라우저에서 푸시 기능을 보내는 대신 메시지를 보냅니다. 다른 웹 서버에서 처리되는 클라이언트 요청이 거의 없는 시나리오가 있을 수 있습니다. 따라서 우리는 백플레인과 백플레인에 차례로 메시지를 브로드캐스트하고 SignalR 메시지를 모든 웹 서버에 보내고 차례로 연결된 모든 클라이언트에 브로드캐스트합니다. 따라서 WebSocket을 사용하여 ASP.NET SignalR backplane 웹 팜이 있는 경우 매우 일반적인 설정입니다.
현재 SignalR Backplane NCache 또는 다른 분산 캐싱 제품을 연결할 수 있습니다. 또한 데이터베이스일 수도 있고 메시지 버스일 수도 있지만 여기서 아이디어는 백플레인에 성능 또는 처리량 문제가 없어야 한다는 것입니다. 매우 잘 수행되어야 하고, 짧은 대기 시간을 제공해야 하며, 높은 처리량을 제공해야 하며, 동시에 다운되어 비즈니스에 영향을 미칠 모든 SignalR 메시지가 손실되는 경우에도 매우 안정적이어야 합니다.
데이터베이스는 느리고 확장성이 좋지 않으며 성능이 느립니다. Redis 옵션은 기본 .NET이 아니므로 매우 확장 가능하고 매우 빠르고 신뢰할 수 있는 것이 필요합니다. 따라서 사용하는 경우 ASP.NET 응용 프로그램 내의 또 다른 문제입니다. SignalR backplane 그 결과. 이렇게 하면 XNUMX가지 병목 현상이 완료됩니다. 정보가 많다는 것을 알고 있지만 주로 데이터베이스가 느리고 확장성이 좋지 않으며 ASP.NET 세션 상태에는 기본적으로 확장성이 뛰어나거나 빠르거나 안정적인 옵션이 없습니다. ASP.NET 웹 팜에 대한 보기 상태는 또한 병목 현상의 원인이며, 대역폭 사용을 통해 응용 프로그램 콘텐츠가 변경되는지 여부에 관계없이 응용 프로그램 내의 정적 페이지가 실행됩니다. 그것은 실행될 것이고 우리는 SignalR Backplane 이것은 일반적으로 느리고 매우 안정적이지 않으며 확장성이 매우 낮고 그에 비해 매우 확장 가능한 매우 안정적인 무언가가 필요합니다.
이것으로 XNUMX가지 병목 현상이 완료되었습니다. 다음 슬라이드에서는 솔루션에 대해 이야기하고 실제로 이러한 모든 병목 현상을 하나씩 살펴보고 다른 솔루션을 제시하겠습니다. 질문이 있는 경우 알려주시면 지금 바로 해당 질문에 답변해 드리겠습니다. 여기에 몇 가지 샘플 샘플 응용 프로그램이 정렬되어 있으므로 잘 사용하겠습니다. 그래서 저는 이 시점에서 질문이 없다고 생각합니다. 다음 부분에서 다룰 내용이 많기 때문에 빠르게 솔루션을 시작하겠습니다.
솔루션: 인메모리 분산 캐시
우리는 메모리 내 분산 캐싱을 솔루션으로 사용하고 있습니다. NCache 예시 제품으로. NCache 주요 분산 캐싱 제품인 .NET 기반 분산 캐시이며 .NET 내에서 작성되었으며 주로 .NET 애플리케이션용이며 당사의 주요 제품 중 하나입니다. 나는 사용할 것이다 NCache 예제 제품으로, 우리는 내에서 다섯 가지 기능에 대해 이야기할 NCache 이 작업을 처리하고 ASP.NET 응용 프로그램 내에서 성능 부스터를 볼 수 있습니다. 그것은 성능과 확장성을 극적으로 향상시킬 것이며 이것은 단지 ASP.NET 특정 기능이며 조정할 수 있는 다른 서버 측 기능이 있으며 별도의 웹 세미나가 있습니다. 개선하는 방법 NCache 성능, 완전히 새로운 수준으로 끌어올려 성능을 더욱 향상시킬 것이지만 이 웨비나에서는 XNUMX가지 병목 현상에 대해 설명한 다음 이러한 병목 현상에 대한 XNUMX가지 다른 솔루션에 대해 설명하겠습니다.
메모리 내 분산 캐시란 무엇입니까?
그렇다면 메모리 내 분산 캐시는 무엇이며 어떻게 더 빠르고 확장 가능하며 어떤 경우에는 더 안정적일까요? 따라서 분산 캐시는 메모리, CPU 및 네트워킹 리소스에 대한 논리적 용량으로 함께 풀링되는 저렴한 여러 캐시 서버의 클러스터입니다. 따라서 서버 팀이 있고 해당 서버 팀이 클러스터로 결합되면 애플리케이션에 대한 논리적 용량이지만 물리적 서버 또는 VM 세트이므로 우리 뒤에는 여러 리소스가 있으며 다음을 수행할 수 있습니다. 즉석에서 더 많은 서버를 추가합니다. 따라서 저렴한 캐시 서버가 함께 결합되어 리소스를 풀링하고 이것이 분산 캐시의 기반을 형성하는 것입니다.
그런 다음 캐시 서버 간에 캐시 업데이트를 동기화했습니다. 여러 서버가 있고 여러 클라이언트 응용 프로그램이 연결되어 있기 때문에 데이터 측면에서 매우 일관성이 있습니다. 따라서 한 캐시 서버에서 수행된 모든 업데이트는 다른 웹 캐시 서버에서 볼 수 있어야 합니다. 또한 그것에 연결된 클라이언트와 나는 가시적이라는 용어를 사용했는데, 이는 일관성이 있어야 함을 의미합니다. 여기에서 복제를 용어로 사용하지 않았습니다. 복제는 또 다른 개념입니다. 따라서 모든 업데이트는 모든 캐싱 서버에 동기화 방식 또는 일관된 방식으로 적용되므로 모든 클라이언트 애플리케이션에 대해 동일한 데이터 보기를 갖게 됩니다.
그런 다음 트랜잭션 및 메모리 용량 및 기타 리소스에 대해 확장해야 합니다. 서버를 더 추가하면 용량이 늘어나야 합니다. 서버가 10,000개이고 세 번째 서버를 가져오면 이전에 세 번째 서버에서 15,000개의 요청을 처리했는데 두 대의 서버가 용량을 두 배로 늘리면 20,000개로 가져와야 합니다. 초당 XNUMX개의 요청을 처리해야 하며 이것이 우리의 경험입니다. 실제로 용량이 증가하고 서버 수를 추가함에 따라 전체 요청 처리 용량이 증가합니다. 이를 지원하는 몇 가지 벤치마크 수치를 보여드리겠습니다. 이것은 일반적인 분산 캐시의 배포 아키텍처입니다.
캐시 서버 팀이 있고 모든 Windows 환경은 2008, 2012 지원되며 모든 애플리케이션은 클라이언트-서버 모델에서 캐시 서버에 연결되며 관계형 데이터베이스와 함께 빠르고 확장 가능하며 안정적인 소스를 사용합니다. 언젠가 그들은 이것이 관계형 데이터베이스에 존재한다는 것을 제공할 것입니다. 당신은 캐시에서 데이터의 일부 또는 전부를 가져올 수 있습니다. 세션 상태는 메인 스토어, 뷰 상태, 출력 캐시, SignalR backplane 이것은 당신의 주요 공급자가 됩니다.
NCache 성능 벤치 마크
확장성이 매우 높다는 것을 뒷받침하는 몇 가지 벤치마크 수치를 보여드리겠습니다. 당사 웹사이트에 이러한 수치가 게시되어 있습니다. 이것은 테스트 세부 사항입니다. 그런 다음 성능을 보면 쓰기에 대해 선형이 아닌 읽기에 대해 증가하고 있지만 이것이 오늘의 웨비나에서 사용할 토폴로지입니다. 읽기 및 쓰기는 선형적으로 증가하고 있습니다. 읽기 및 쓰기는 백업뿐만 아니라 선형적으로 증가합니다. 따라서 이것은 백업 지원도 함께 제공되기 때문에 쓰기 성능이나 용량이 파티션에 백업이 없는 것보다 약간 작기 때문에 백업 오버헤드도 있습니다. 따라서 이것은 읽기 및 쓰기에 가장 널리 사용되는 토폴로지이며 더 많은 서버를 추가하면 실제로 용량도 확장됩니다.
데모에 손
데모 환경으로 이동하여 분산 캐시를 설정한 다음 이러한 기능을 하나씩 시작하겠습니다. 질문이 있으면 말씀해 주십시오.
사용하겠습니다. 이미 다운로드하여 설치했습니다. NCache, 이 웹 세미나의 범위는 주변에 없습니다. NCache 구성 또는 설정. 따라서 여기에서 일부 세부정보는 건너뛰지만 알려 드리기 위해 다운로드 NCache 우리 웹 사이트에서 완전히 작동하는 평가판을 얻은 다음 두 개의 캐시 서버 상자에 설치했으며 내 쪽의 한 컴퓨터는 클라이언트로 사용할 것입니다. 당신은 설치할 수 있습니다 NCache 클라이언트에서도 사용하거나 필요에 따라 NuGet 패키지를 사용할 수 있습니다.
캐시 생성
저는 그냥 캐시를 만들겠습니다. 이름을 aspnetcache로 지정하겠습니다. 왜냐하면 그것이 오늘 우리가 집중하고 있는 것이기 때문입니다.
파티션 복제본 캐시를 선택하고 이러한 모든 설정은 일반 문서에서 자세히 설명합니다. NCache 아키텍처 웨비나.
비동기 복제 옵션과 여기에서는 처음에 내 캐시 클러스터의 일부가 될 서버를 지정합니다.
TCP/IP 포트에 대해 모든 것을 동일하게 유지하십시오. NCache TCP/IP 기반 통신이며 서버-서버 통신 및 클라이언트-서버는 TCP/IP를 통해 관리되고 각 서버의 캐시 크기는 모든 것을 기본값으로 유지하고 축출 기본값을 유지하고 마침을 선택하면 됩니다.
캐시를 설정하는 방법은 간단합니다. 오른쪽 창에는 이 캐시와 관련된 모든 설정이 있으며 명령줄과 powerShell 도구를 설정한 다음 명령줄이나 powershell에서도 모든 것을 관리할 수 있습니다. 응용 프로그램을 실행할 계획인 mybox를 추가하겠습니다. 따라서 클라이언트 측 구성이 업데이트되고 이 캐시에 연결할 수 있으므로 이 캐시 클러스터를 시작하고 테스트하면 됩니다. 이 시점에서 내 서버 사이트 설정이 완료되었습니다. 여러분, 질문이 있으면 알려주세요. 자, 이제 시작되었습니다. 마우스 오른쪽 버튼을 클릭하고 통계를 선택하겠습니다.
Ron, 질문이 있습니다. NCache JSP 세션에 대한 Java 응용 프로그램을 지원하는 흐름 세션 캐싱 또는 ASP.NET 응용 프로그램입니까? 좋습니다. 이 웹 세미나는 주로 ASP.NET에 초점을 맞추었기 때문에 ASP.NET 사이트에 더 초점을 맞추었지만 이 질문에 대답하기 위해 그렇습니다. NCache Java 응용 프로그램을 완벽하게 지원하며 Java 클라이언트가 있으며 Java 응용 프로그램의 경우 Java 웹 세션 또는 JSP 세션이 있는 경우 잘 사용할 수 있습니다. NCache. 따라서 공급자는 정확히 동일하게 유지되며 코드 변경이 없는 옵션이며 함께 설치되는 샘플 응용 프로그램이 있습니다. NCache 또한. 따라서 설치하기만 하면 됩니다. NCache Windows 환경에서 또는 컨테이너를 사용할 수도 있고 응용 프로그램이 Windows에 있을 수도 있고 Linux UNIX 환경에도 있을 수 있으며 Java 응용 프로그램을 완벽하게 지원합니다.
캐시 통계 모니터링
몇 가지 모니터링 측면을 보기 위해 통계를 열었습니다. 함께 설치되는 모니터링 도구도 열었습니다. NCache. 내 캐시가 제대로 구성되었는지 확인하기 위해 스트레스 테스트 도구 응용 프로그램을 빠르게 실행하고 다음에는 실제로 샘플 응용 프로그램을 시작하겠습니다. 하나의 클라이언트가 연결되어 있습니다. 바로 여기에 몇 가지 활동이 표시되어야 합니다. 그러면 카운터가 있습니다. 두 서버의 초당 요청 값을 표시하고 일부 그래프가 이미 채워져 있습니다.
따라서 모든 것이 올바르게 구성되었는지 확인한 다음 샘플 애플리케이션을 시작할 수 있습니다.
따라서 첫 번째 샘플 응용 프로그램은 XNUMX가지 다른 최적화입니다. 나는 이러한 것들에 대해 하나씩 이야기하고 샘플 응용 프로그램을 보여 드리겠습니다. 우선, 당신은 사용할 수 있습니다 NCache 데이터 캐싱을 위해 데이터베이스 병목 현상에 대한 자세한 API가 있습니다. 빠른 인메모리 분산 캐시를 사용할 수 있습니다. 메모리에 있기 때문에 더 빠르고 더 많은 서버를 추가한 다음 더 많은 서버를 추가하여 런타임에 용량을 늘릴 수 있기 때문에 확장성이 더 좋습니다. 세션 상태에 사용할 수 있습니다. 이것은 코드 변경이 없는 옵션이며 세션은 다음에서 매우 안정적입니다. NCache 복제되기 때문에 세션도 빠르고 확장 가능한 저장소에서 관리되며 고정 세션 로드 밸런싱이 필요하지 않습니다. 이 샘플 애플리케이션을 실제로 보여주면 더 많은 이점에 대해 이야기하겠습니다. NCache 연결하자마자 바로 NCache 이것들을 위해.
웹 팜의 경우 보기 상태를 사용할 수 있고 서버 끝에 보기 상태를 저장할 수 있으며 보기 상태를 보낼 필요가 없으며 보기 상태 페이로드 크기도 줄인 다음 사용할 수 있습니다. NCache for SignalR Backplane, 이것이 네 번째 옵션이며 다음을 사용할 수도 있습니다. NCache 출력 캐싱과 정적 콘텐츠의 경우 ASP에서도 마찬가지입니다..NET core. ASP 내에서 세션 상태에 사용할 수 있습니다..NET core ASP의 응답 캐싱에도 사용할 수 있습니다..NET core 분야의 다양한 어플리케이션에서 사용됩니다.
ASP.NET 세션 캐싱 샘플
이제 ASP.NET 세션 상태 저장소를 시작하겠습니다. 이것은 무엇보다도 XNUMX분 이내에 설정하고 빠르게 테스트할 수 있습니다. 사실, 설정하고 시작하는 방법을 보여 드리겠습니다.
이것이 우리의 첫 번째 샘플 응용 프로그램입니다. 제가 한 것은 NCache 도 있지만 약간 수정했습니다. 세션 캐싱의 경우 어셈블리 태그를 추가하기만 하면 됩니다. 이 두 어셈블리는 중복됩니다. 이들은 객체 캐싱의 또 다른 사용 사례이지만 Alachisoft.NCache.SessionStoreProvider 어셈블리. 버전 4.9가 최신 버전이므로 이 어셈블리에도 문화권과 공개 토큰이 필요합니다. 따라서 이것은 이 세션 상태 어셈블리에 대한 일반적인 참조입니다. 이 후에 기존 세션 상태 태그를 다음으로 교체해야 합니다. NCache. 세션 상태 태그가 이미 있는 경우 교체해야 하고, 없는 경우 InProc였습니다. 이 경우 실제로 교체할 수 있으며 이를 새로 추가할 수 있습니다. 여기서 모드는 사용자 정의이고 공급자는 NCacheSessionsProvider, 시간 초과 값은 세션 개체가 NCache XNUMX분 이상 유휴 상태를 유지하면 캐시에서 자동으로 만료됩니다.
그런 다음 활성화할 예외와 같은 몇 가지 설정이 있습니다. 따라서 이것은 샘플 태그로 사용할 수 있습니다. 여기에서 복사하여 응용 프로그램에 붙여넣을 수 있으며 가장 중요한 것은 캐시 이름입니다. 캐시 이름 aspnetcache를 지정하기만 하면 됩니다. 나는 같은 이름의 aspnetcache를 사용하고 이름만 지정하기 때문에 이 샘플의 구성을 해결할 것이라고 생각합니다. 따라서 client.ncconf aspnetcache에서 이 캐시에 대한 구성을 읽거나 이 파일을 프로젝트의 일부로 만들 수도 있습니다. NuGet 패키지가 있는 경우 실제로 이 파일을 프로젝트의 일부로 만들 수도 있습니다. 여기에서 두 페이지를 사용하고 있었기 때문에 이것을 저장하고 이것을 메인 페이지로 만들도록 하십시오. 이것을 실행하면 제공자를 위한 게스트 게임 세션이 시작되고 연결됩니다. NCache 세션 데이터용.
따라서 캐시에 세션 개체를 생성한 다음 세션에서 일부 데이터를 다시 읽고 생성되는 세션 개체도 보여 드리겠습니다. 이것은 추측 게임 응용 프로그램으로, 0에서 23 사이의 숫자를 추측할 수 있게 하고 실제로 세션 개체에서 이전 게스트를 인쇄합니다. 그래서 숫자가 12과 12 사이라고 추측했습니다. 그래서 저는 23를 추측할 것입니다. 숫자는 13와 23 사이입니다. 그래서 마지막 숫자도 읽습니다. 숫자가 XNUMX에서 XNUMX 사이라고 가정해 보겠습니다. 한 번 더 추측해 보겠습니다. 추측할 수는 없지만 거기에 도달할 수 있기를 바랍니다. 그러나 세션 개체가 서버 측에서 생성되었음에 틀림없다는 것을 알려드리기 위해서입니다.
도구를 사용하여 이것을 보여 드리겠습니다. NCache test는 이 샘플 애플리케이션에 추가한 키워드입니다. 변경하면 서로 다른 응용 프로그램의 세션을 구별하기 위한 것입니다. 두 개의 응용 프로그램이 있고 두 응용 프로그램에 대해 동일한 캐시를 사용하는 시나리오가 있을 수 있습니다. 따라서 이 경우 세션 변수에 앱 ID를 추가할 수 있지만 일반적으로 하나의 애플리케이션은 해당 세션을 전용 캐시에 캐시해야 합니다. 따라서 빈 문자열로 지정하더라도 이것이 생성되고 이것이 ASP.NET 세션 ID인 경우에는 여기 세션이 바로 여기에 복제됩니다. 따라서 이 서버가 다운되면 세션 데이터를 자동으로 사용할 수 있게 됩니다.
몇 가지 더 많은 혜택 NCache InProc과 비교하여 세션 상태가 프로세스를 벗어나므로 웹 프로세스는 완전히 상태 비저장입니다. 따라서 HTTP 프로토콜에서 선호하는 방식으로 확장성이 더 뛰어나고 리소스를 더 추가할 수 있으며 메모리 내이므로 더 빠르고 InProc와 비교할 수 있으며 매우 안정적입니다. 서버가 다운되면 아무것도 걱정할 필요가 없으며 가장 중요한 것은 더 이상 고정 세션이나 밸런싱을 사용할 필요가 없다는 것입니다. 동일한 로드 밸런싱을 가질 수 있고 요청이 한 웹 서버에서 다른 웹 서버로 바운스될 수 있습니다. 웹 서버는 아무것도 저장하지 않고 실제 세션 객체는 NCache 이것은 StateServer의 응용 프로그램 및 비교를 위한 외부 프로세스 저장소입니다. 단일 실패 지점이 아닙니다. 서버가 다운되거나 유지 관리를 위해 다운되더라도 아무 걱정할 필요가 없으며 문제 없이 작동합니다.
둘째, 확장성이 매우 뛰어나 즉시 더 많은 서버를 추가할 수 있습니다. 그것은 매우 안정적이고 확장성이 뛰어나며 그에 비해 빠릅니다. 데이터베이스의 경우 느리지 않고 빠르며 매우 확장 가능하며 어떤 경우에는 데이터베이스에 대한 복제가 없는 안정성 측면에서 훨씬 더 좋습니다. 따라서 여기에는 다음과 같은 중요한 기능이 하나 더 포함됩니다. NCache 우리의 다중 사이트 세션 지원은 또 다른 기능입니다. 다중 지역 세션, 두 개의 서로 다른 지역에서 세션이 저장될 NCache 완전히 동기화된 세션을 가질 수 있습니다.
세션 요청이 한 서버에서 다른 서버로 또는 한 지역에서 다른 지역으로 반송되는 경우 해당 지역 전체에 자동으로 세션이 제공되어 여기로 가져오거나 그 반대의 경우도 마찬가지입니다. 따라서 측면을 아래로 가져와야 하는 경우 일정 기간 동안 캐시를 계속 실행하여 모든 트래픽을 반대편으로 라우팅할 수 있습니다. 그래서, 그것은 또 다른 기능입니다. 주요 항공사 중 하나인 항공사 고객은 실제로 위치 선호도에 이 기능을 사용하고 있습니다. 따라서 이것은 ASP.NET 세션 상태를 다룹니다. 이것은 코드 변경이 없는 공급자입니다. 이에 대해 질문이 있으면 알려주세요. 그러면 JSP 세션에 대한 질문에 이미 답변을 받았으니 사용할 수 있습니다. NCache Java 기반 웹 세션에서도 사용할 수 있습니다. 질문이 없다고 가정합니다.
ASP.NET View State 캐싱 샘플
다음으로 뷰 상태에 대해 이야기하겠습니다. NCache 또한 뷰 상태 공급자가 있습니다. 작동 방식은 기본적으로 서버 측에서 뷰 상태를 유지하는 것입니다. 다시 공급자입니다. 섹션 그룹을 올바르게 설정하기만 하면 됩니다. 바로 콘텐츠 설정이고 ContentOptimization.Configurations.ContentSettings입니다. 섹션 그룹의 이름은 nContentOptimization이고 여기에는 캐시 이름을 사용하는 몇 가지 설정이 있습니다. 예를 들어 저는 지금 mycache를 사용하고 있습니다. ASP.NET view state 공급자는 우리가 서버 쪽 오른쪽에서 보기 상태를 유지한다는 것입니다. 따라서 우선 이전 공급자가 연결되어 있지만 캐싱 없이 실행할 것입니다. 그러나 뷰 상태 캐싱을 false로 설정하고 이것을 실행하고 실제 뷰 상태가 되돌아가는 모습을 보여드리겠습니다. 브라우저에.
그래서 기본 옵션을 보여주고 NCache 상태를 보고 그 차이를 비교하겠습니다. 그래서 몇 페이지 웹 팜이 있으며 보기 페이지 소스를 보여 드리겠습니다.
이것은 기본 보기 상태, 값 부분입니다. 여기로 가져오고 여기에서 임시 문서를 만들겠습니다. 이제 이것은 내 응답 패킷의 일부인 기본 보기 상태이며 이 페이지에서 다시 푸시하면 내 요청 패킷의 일부가 됩니다. 그것은 개별 요청이며 요청 및 응답 헤더에 얼마나 많은 문자가 추가되었는지 확인하십시오. 이것은 내가 만들 모든 요청에 대해 동일합니다. 몇 가지 요청을 더 보여주고 이 요청의 보기 페이지 소스도 보여드리겠습니다.
따라서 화면에서 볼 수 있는 것과 거의 유사합니다. 지금 NCache 우리가 한 것은 뷰 상태 공급자의 도움으로 뷰 상태를 가로채는 것입니다. 우리는 서버 측에서 보기 상태를 유지하므로 이 값 부분은 웹 팜의 주어진 페이지에 대한 키와 값을 생성하고 서버 측에서 저장하고 이제 서버 측에서 저장하므로 작은 토큰을 보냅니다. 브라우저로 돌아갑니다. 따라서 브라우저로 다시 전송되는 정적 크기 토큰입니다. 그것은 실제로 변경되지 않으며 항상 그곳으로 전송된 다음 다시 사용하기 위해 다시 가져오고 다시 게시할 때 실제로 전화를 겁니다. NCache 에서 추가 보기 상태를 가져옵니다. NCache 그런 다음 실제로 보기 상태를 위해 웹 팜에서 사용합니다. 이것이 우리가 무대 뒤에서 하는 일입니다.
보기 상태 패킷을 얻는 이점은 토큰이기 때문에 크기가 더 작아집니다. 따라서 요청 및 응답에 대한 페이로드 크기를 줄이는 전반적인 영향이 있습니다. 따라서 성능이 향상되고 두 번째로 수천 개의 요청에 대해 수백 킬로바이트의 보기 상태가 왔다 갔다 하는 경우 대역폭을 소모하게 됩니다. S, 이것은 일어나지 않을 것입니다 NCache, NCache 보기 상태는 정적 토큰이며 토큰을 정말 빨리 보여 드리겠습니다.
Ron, 질문으로 넘어가겠습니다. 정말 빠르죠. NCache 세션 암호화 및 보기 상태 캐싱과 같은 청구서 보안 기능이 있습니까? 예, 명시적으로 설정할 수 있는 기능이며 일반적인 기능입니다. NCache 특징. 따라서 모든 보기 상태는 이미 암호화된 문자열이지만 추가로 암호화하고 주변에 있는지 확인하려면 캐시 자체에서 암호화를 활성화하여 중지하고 암호화를 설정해야 합니다. DES 공급자가 있습니다. , AES 공급자가 있고 FIPS 클라이언트, FIPS 준수, DES AES 공급자가 있습니다. 예, 간단히 설정하면 클라이언트-서버의 모든 페이로드가 여기에서 암호화 및 해독되고 각각 가져옵니다. 따라서 이것은 요청 시 설정할 수 있고 작업을 진행할 수 있는 것입니다. 이 질문을 통해 다음과 같이 강조하고 싶습니다. NCache 이것은 저장하지 않은 후의 보기 상태입니다. NCache 연결됨이 공급자로 연결되어 차이점을 알 수 있습니다. 이렇게 많은 문자와 많은 문자가 있다는 것입니다. 이것이 기본이며 다음과 같습니다. NCache 속도가 느려지고 페이로드 크기가 줄어들고 모든 성능이 향상되고 대역 가상화 비용이 감소한다는 차이점을 직접 확인하십시오. 따라서 아키텍처에서 많은 개선 사항을 볼 수 있으며 가장 중요한 것은 실제 보기 상태가 더 이상 브라우저로 실제로 다시 전송되지 않는다는 것입니다. 서버 측에 저장될 것이며 일반적으로 안전합니다.
따라서 이 질문을 바탕으로 이렇게 질문해 주셔서 감사합니다. NCache 보기 상태는 기본적으로 기본 옵션보다 더 안전합니다. 실제로 필요한 서버 쪽에 저장하기 때문입니다. 도움이 되기를 바랍니다. 뷰 상태에 대한 질문은 이 부분을 닫고 다음 부분으로 넘어가겠습니다.
애플리케이션 데이터 캐싱 샘플
시간 제약 때문에 객체 캐싱을 먼저 보여드리겠습니다. 나는 이것을 먼저 덮어야 한다고 생각한다. 데이터베이스 병목 현상의 경우 데이터베이스에 저장하여 속도를 늦추는 모든 것이 대안으로 다음과 같은 분산 캐시를 사용할 수 있습니다. NCache. 이것은 NCache 여기 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");이것이 캐시를 연결하는 방법입니다. 작업을 수행하는 쪽 끝으로 핸들을 배치하는 방법입니다. 모든 것이 키 값 쌍에 저장되고 문자열 키 값입니다. .NET에서 허용한 개체로 데이터 테이블을 도메인 개체에 매핑할 수 있습니다. 그런 다음 도메인 개체를 저장한 다음 관계가 있는 개별 개체 또는 컬렉션을 저장하여 도메인 개체를 처리합니다. SQL은 목록을 검색하지만 이것은 기본적인 생성, 읽기, 업데이트, 삭제 작업입니다.
샘플 응용 프로그램을 빠르게 실행하고 실제로 사용하는 방법을 보여 드리겠습니다. NCache 개체 캐싱을 위해. 이 두 가지 요약 참조가 필요합니다. Alachisoft.NCache.웹 및 Alachisoft.NCache.실행 시간. 이 작업을 완료하면 이 페이지를 시작 페이지로 만들고 이에 대한 코드를 보여드리겠습니다. 이것은 ASP.NET 웹 팜이지만 컨트롤러 MVC가 있는 경우 동일한 접근 방식을 사용할 수도 있고 이 네임스페이스가 바로 여기에 있고 이 애플리케이션 내에서 mycache를 초기화하고 있으므로 캐시의 이름을 지정해야 하고 여기에서 InitParams 오른쪽 캐시 InitParams를 사용하여 여기에서 서버를 지정할 수도 있습니다. 또는 이름을 지정하고 앞서 보여드린 client.ncconf를 통해 이름을 확인할 수도 있습니다. 고객을 추가하는 addObject가 있습니다. 이름은 David Jones, 남성, 연락처 번호, 이것은 주소이고 저는 cache.Add를 호출합니다.
마찬가지로, 페이지를 변경하여 이것을 삽입하고 있습니다. 그렇지 않으면 실제로 이름도 변경하여 이것이 업데이트되었는지 확인한 다음 cache.Insert를 호출하고 객체를 다시 가져와서 개체 수. 해당 개체를 제거하고 부하 테스트를 실행 중입니다. 100개의 항목이 계속해서 업데이트될 예정입니다. 샘플 응용 프로그램을 실행해 보겠습니다. 이 응용 프로그램을 시작하는 것이 얼마나 직관적인지 알 수 있습니다. 응용 프로그램을 실행하기만 하면 이러한 모든 작업을 수행할 수 있습니다. 실제로 이 작업을 수행하기 전에 캐시된 보기 상태를 표시하기 위해 NCache.
세 페이지 대 뷰 상태에 대한 키를 볼 수 있으며 이것은 객체의 실제 키이고 실제 뷰 상태는 값 부분에 있습니다. 내용을 지우도록 했다고 가정하고 지금 언급하는 것을 잊었습니다. 따라서 지금은 개체 캐싱 데이터만 다루므로 실제로 관리자에서 이 작업을 수행하면 편리합니다. 그래서 나는 개체를 추가할 것이고 고객은 내가 이 개체를 다시 가져올 것이라고 덧붙였습니다. 그래서 우리는 23세의 David Jones를 가지고 있습니다. 업데이트한 다음 추가하고 다시 가져옵니다. 이제 David Jones 2입니다. 그런 다음 우리는 연령으로 50을 갖게 됩니다. 다시 가져와 캐시 1의 항목을 제거하겠습니다. 이 객체는 다시 캐시 0에 있는 항목을 한 번 더 삽입합니다. 삽입이 추가되고 객체를 다시 가져오면 캐시에서 이것을 보여드릴 수 있습니다. 그래서 저는 이 시점에서 하나의 개체를 다루고 있었고 키는 여기에 추가된 고객 이름의 고객이었습니다. 그런 다음 로드를 시작하고 지금 테스트합니다. 캐시에서 일부 활동이 표시되고 요청이 들어오고 데이터를 처리하는 클라이언트 요청이 있습니다.
이 덤프 캐시 키를 다시 실행하면 함께 덤프된 XNUMX개의 키만 표시됩니다. 제가 추가한 키들입니다. 따라서 개체 캐싱을 시작하는 것이 얼마나 간단한지 알 수 있습니다. 데이터베이스에 속한 모든 데이터는 속도를 늦추고 확장성을 제한할 수 있습니다. NCache 객체 캐싱을 사용합니다. 도메인 개체, 컬렉션, 데이터 세트, 이미지 모든 종류의 응용 프로그램 관련 데이터가 개체 캐싱 모델을 사용하여 캐시될 수 있습니다. 이것이 도움이 되기를 바랍니다. 시작하겠습니다. 좋습니다. 여기에서 다음 데이터 캐싱을 다룹니다. SignalR Backplane.
ASP.NET SignalR Backplane 견본
얘기하자. 시그널R. 과 NCache 우리는 강력한 게시/구독 메시징 플랫폼. 따라서 샘플 애플리케이션이 있으며 NuGet 패키지도 보여 드리겠습니다. NCache 라이브러리는 설치와 함께 설치되거나 NuGet 패키지를 사용할 수 있습니다. 따라서 온라인 NuGet 리포지토리로 이동하여 NCache, 모든 NuGet 패키지가 표시됩니다. Alachisoft.NCache.SDK는 개체 캐싱용이고 Linq는 linq 쿼리용이며 세션 상태 공급자가 있으며 오픈 소스 및 커뮤니티도 있습니다.
이것은 이 애플리케이션에 포함된 NuGet 패키지입니다. 그냥 빌드하고 NuGet 패키지가 추가되어 있어야 하므로 제대로 작동하는지 봅시다. 좋아, 위해 SignalR Backplane SignalR NuGet 패키지가 추가되었는지 확인하기만 하면 됩니다. 즉, 아직 설치되지 않은 경우 설치하는 것입니다. 따라서 NuGet 패키지를 추가한 후 추가해야 하며 필요에 따라 일부 SignalR 어셈블리와 도움이 되는 일부 어셈블리를 추가한 후 web.config로 이동하면 거기에 일부 설정을 추가했습니다. 캐시의 myname은 aspnetcache입니다. 그 다음에는 원하는 주제의 이름인 이벤트 키입니다. 따라서 실제로 이 특정 채팅 응용 프로그램에 대한 SignalR 채팅 메시지 또는 SignalR 메시지를 전송하려는 주제 이름을 제공하고 싶은 경우 지정한 위치에서 코드 한 줄만 변경하면 됩니다. 캐시의 이름과 이벤트 키 및 포인터 NCache 샘플 애플리케이션을 실행합니다. 그것은 자동으로 사용할 것입니다 NCache SignalR 백플랜의 경우, NCache 플러그 인이 얼마나 간단한지 백플랜이 됩니다. NCache SignalR 애플리케이션용.
기본 .NET과 달리 얻을 수 있는 이점 Redis 데이터베이스 및 메시지 버스에 비해 빠르고 확장 가능하며 신뢰할 수 있으며 이를 뒷받침하는 완벽하게 작동하는 게시/구독 모델이 있습니다. 따라서 게시/구독 메시징을 직접 사용할 수도 있지만 게시/구독 메시징의 사용 사례 중 하나의 확장은 SignalR Backplane 설정하는 것도 매우 쉽습니다.
그래서 이 응용 프로그램이 시작되었습니다. 여기 열쇠가 있을 텐데 열쇠 찾기가 어려울 것 같은데 채팅으로 보여드리기 위해 NCache, 이것은 작동하며 다른 사용자(예: Nick)에 서명하여 이것을 다른 브라우저로 전송할 것입니다. 이것을 다시 가져오면 실제로 연결된 다른 클라이언트에도 메시지를 브로드캐스트했음을 알 수 있습니다. 그래서, 그것은 얼마나 쉽습니다. 한 번만 더 물어보고 예상대로 작동하는지 확인하겠습니다. 그럼 시작하겠습니다. 그래서, 이것은 NCache 설정하기가 매우 쉽고 이것이 설정하고 마지막 기능을 사용하는 방법입니다. NCache, 다섯 번째 부스터는 출력 캐싱입니다.
Ron, 내에서 시각적 개체로 저장된 SignalR 메시지인 SignalR에 대해 질문이 있습니다. NCache 또는 NCache 알림을 사용하시겠습니까? NCache 이를 위해 pub/sub 알림을 사용합니다. 그래서 우리는 백그라운드에 있는 pub/sub 메시징 플랫폼을 가지고 있습니다. 캐시 자체에서 하나의 객체만 보거나 주제이기 때문에 객체를 보지 못할 것입니다. 따라서 생성되는 주제가 있습니다. 여러 작업 프로세스가 연결되어 실제로 브로드캐스트되는 논리적 터널입니다. NCache, 해당 주제에 대한 모든 SignalR 메시지. 따라서 캐시에 추가된 많은 메시지를 볼 수 있는지 묻는 경우 알림 프레임워크입니다. 아니요. 한 가지 주제만 보고 주제 내에 메시지가 있는 것입니다. 토픽 내에 얼마나 많은 메시지가 있는지 보기 위해 시각화할 수 있는 몇 가지 통계가 popper 만남에 있지만 개별 객체에 관한 한 이러한 객체는 볼 수 없으며 하나의 객체만 주제로 볼 수 있습니다. 도움이 되기를 바랍니다.
ASP.NET 출력 캐싱 샘플
이 안에 있는 마지막 기능인 우리도 시간이 부족하다고 생각합니다. 빠르게 살펴보겠습니다. 우리의 출력 캐싱이므로 출력 캐싱 섹션을 설정하기만 하면 됩니다. NCache 출력 캐시 공급자 dll. 여기가 바로 여기에 있습니다. 이러한 참조가 필요합니다. Ncache.Adapters, web, runtime in cache 그리고 그 후에 N 출력 캐시 공급자를 참조하고 캐시 이름을 aspnetcache로 설정하면 버전이 최신이어야 합니다. 작동 방식은 실제로 정적 페이지의 출력을 캐시하고 실행하기만 하면 정적 페이지의 출력을 캐시한다는 것입니다. 전체 페이지 또는 페이지 내의 일부가 정적이고 이 지시문 출력 캐시로 일부 정적 페이지를 장식하는 경우 기간, 위치 및 VaryByParam을 지정하십시오. 이 매개변수가 변경되지 않으면 자동으로 동일한 출력임을 의미합니다.
따라서 캐시된 출력이 최종 사용자에게 표시되고 페이지를 실행할 필요가 없으며 데이터베이스를 포함할 필요가 없으며 작업자 프로세스의 부하를 데이터베이스에서 제거하고 값비싼 CPU 및 시스템 리소스를 절약하고 최종 클라이언트가 사용할 수 있는 기성품 페이지 출력을 얻으십시오. 따라서 전반적으로 성능이 향상되고 ASP.NET은 이를 기능으로 제공하고 NCache 매우 확장 가능하고 매우 빠르며 매우 안정적인 페이지 출력이 저장된 분산 수준으로 이동합니다. NCache 코드 변경 없이 이것은 ASP에 해당됩니다..NET core 뿐만 아니라, 당신은 당신이 사용할 수있는 방식으로 사용할 수 있습니다 NCache ASP 내에서.NET core 웹 애플리케이션도 마찬가지입니다. 이에 대해 별도의 웨비나를 진행했으며 idistributed 캐시가 있는 경우 세션 스토리지와 ASP도 있습니다..NET core EF 코어 캐싱과 함께 응답 캐싱.
이것이 제가 강조하고 싶었던 몇 가지 기능입니다. 이로써 XNUMX가지 성능 향상 장치가 완성되었습니다. 마음에 드셨기를 바랍니다. 다른 질문이 있으면 알려주세요. 저희도 시간이 너무 촉박하다고 생각합니다. 따라서 다른 질문이 있는 경우 해당 질문을 할 시간이므로 알려주시기 바랍니다.
일반적으로 나는 또한 그것을 언급하고 싶습니다 NCache 완전 탄력적인 XNUMX% 가동 시간 동적 캐시 클러스터이며 단일 실패 지점이 없습니다. 우리는 암호화, 보안, 압축, 이메일 경고, 데이터베이스 동기화, 검색과 같은 SQL, 연속 쿼리, pub/sub 모델, 관계형 데이터와 같은 많은 토폴로지와 기능을 보유하고 있습니다. NCache, 이들은 모두 다른 기능의 일부로 다루어집니다. 따라서 이와 관련된 특정 질문이 있는 경우 해당 질문도 자유롭게 질문해 주세요. 그렇지 않은 경우에는 이 질문을 끝내고 Nick에게 전달하겠습니다.
Ron에게 감사드립니다. 마지막 질문은 세션 캐싱을 위한 사용자 지정 공급자를 설정할 수 있다는 것입니다. NCache? NCache 이미 사용자 지정 공급자입니다. NCache 사용자 지정 공급자 아래에 있는 경우 기본 모드는 InProc, State Server 또는 SQL Server이고 ASP.NET의 네 번째 모드는 사용자 지정입니다. 그래서, NCache 공급자 자체는 사용자 지정 공급자입니다. 이 질문에 대해 특정 요구 사항이 있는 경우 약간 혼란스럽습니다. 그렇지 않으면 알려주십시오. NCache 그 자체가 ASP.NET용 사용자 지정 공급자입니다.
좋아요 Ron, 감사합니다. 더 이상 질문이 없다면 오늘 참석해 주신 모든 분들께 감사드립니다. 이에 대한 귀중한 통찰력을 제공해 주신 Ron에게 다시 한 번 감사드립니다. 질문이 있는 경우 언제든지 이메일을 보내 연락할 수 있습니다. ~에 support@alachisoft.com. 다음 주소로 이메일을 보내 저희 영업 팀에 연락하실 수 있습니다. sales@alachisoft.com 영업 팀의 누군가가 기꺼이 귀하와 협력하고 귀하의 모든 질문에 대한 답변을 확인하고 필요한 모든 정보를 제공하고 당사 웹사이트에서 평가판을 다운로드할 수 있다고 제안합니다. NCache, 30일 평가판이 함께 제공됩니다. 우리는 또한 유료 지원 옵션과 무료 오픈 소스 에디션이 있는 중재를 가지고 있습니다. XNUMX년 동안 많은 콘텐츠가 있습니다. 함께 해주신 모든 분들께 감사드리며 다음에 또 뵙겠습니다. 감사합니다.