웹 인프라

ASP.NET 응용 프로그램에 대한 확장성 제공하는

Iqbal Khan

한 눈에 보기:

• ASP.NET 응용 프로그램의 확장성 병목 현상
• 세션 상태 저장소 옵션
• 사용 가능한 캐싱 토폴로지
• 필요한 분산 캐시 기능

내용

다음 문제?
이러한 문제 없음
다음 응답 무엇일까요?
토폴로지 캐싱
다른 선택
Real World

ASP.NET, Microsoft, 웹 응용 프로그램 프레임워크 popularity leaps, 개발자, 엔터프라이즈 및 IT 차수가 내의 범위 단위로 증가 계속. 그러나 한 영역의 난이도, 있을: 상자 밖으로 ASP.NET 응용 프로그램을 배율 수는 간단히 없습니다.

확장성이 이 두 의미가 있습니다. 먼저 모든 응용 프로그램을 peaks 및 시간 에서 언제든지 로그인한 사용자 수에 대한 측면에서 하강 곡선 거치는 때문에 최대 사용자 로드 효과적으로 처리할 수 있어야 합니다. 인프라를 디자인할 때 효율적이고 빠르게 같은 것으로 nonpeak 로드 같이 최대 로드를 처리할 수 있도록 응용 프로그램을 디자인할 할.

둘째, 전체 시스템 용량을 늘릴 수 합니다. 오늘 경우에만 5, 000명의 사용자가 할 수 있습니다. 도로, 아래로 1년 6개월 10, 000개의 15,000 또는 20,000, 있을 수 있으며 몇 년 동안 에서 수 끝낼 수 위로 10만 사용자와. 사용자 수와 함께 사용하여 정지한다 응용 프로그램을 grinding 없이 커질 수 있는 어떤 확장성을 모두에 대한. 뛰어난 방식으로 성능에 부정적인 영향을 주지 않고 더 많은 사용자를 추가할 수 또는 적절한 범위 내에서 될 합니다 모든 저하될 있으면 의미합니다.

일반적인 ASP.NET 응용 프로그램의 모든 웹 서버에 소통량의 분배할 로드 균형 있는 웹 팜에 있는 함께 연결된 하나 이상의 웹 서버에서 배포됩니다. 이론적으로, 추가한 이상의 웹 서버가 더 많은 요청을 합니다 초당 처리할 수. ASP.NET 확장성 부여하는 웹 팜 아키텍처는 보여 줍니다. 있는 경우 이론적으로는 않으며, 실제로 약간 다릅니다.

ASP.NET 응용 프로그램의 문제는 웹 기술을 웹 팜 및 로드 balancers 세련된 아키텍처를 제공하지만 데이터 저장소 기술이 있어야 않은 유지하도록 위로 것입니다. 분명히 수 있습니다 확장할 웹 응용 프로그램에서 서버를 더 추가하는 또는 자세한 메모리 및 CPU 개별 서버에 강도를 증가.

하지만 데이터 저장소 같은 비율로 확장할 수지 않습니다 있는 마찬가지로. 배율지 않습니다, 있지만 않은 같은 훨씬 웹 응용 프로그램 계층에서 같이. 따라서 데이터 저장소 또는 데이터 액세스 연결된 ASP.NET 응용 프로그램에서 모든 잠재적인 확장성 병목 현상이 있습니다. 배율을 더 지점에 데이터베이스 서버에 조정하지 않습니다 세션 또는 응용 프로그램 데이터에 대한.

다음 문제?

ASP.NET 응용 프로그램 내에서 세션 저장소 시작하는 수행할 다른 액세스 또는 저장소 작업을 살펴보겠습니다. 모든 사용자 요청에 세션은 부분에서 저장소에서 읽고 응답 끝에 저장소를 다시 쓸. 사용자 요청 부분에 페이지를 실행할 수 있으며, 그에 대한 세션 데이터가 필요한. 이를 실행하는 동안 페이지 데이터를 참조할 수 있도록 " 세션 개체 " 라는 전체 세션 데이터가 로드됩니다. 페이지를 세션 개체에서 일부 데이터를 읽을 것입니다. 세션 개체를 일부 자세한 데이터를 넣지 것이 됩니다. ASP.NET 프로세스 내의 이 모든 일이 있으며 세션 저장소 트립 이루어집니다.

페이지 끝나면 사용자가 다시 보낼 수 하는 결과 실행 일부. 이제 세션 저장소에 저장할 권한이 있도록 세션은 대개 이 시간 동안 업데이트됩니다. 해당 됩니다 수 저장 같은 세션에 대한 다음 사용자 요청을 때까지 유지되고 자체를 동일한 프로세스를 반복합니다.

사용자의 관점에서 링크를 클릭하면; 사용자가 해당 링크를 통해 결과 페이지를 볼 때, 세션이 있는 않은 읽고 세션을 갖고 않은 씁니다 다시 저장소에 한. 따라서 ASP.NET 응용 프로그램에서 수행한 세션 저장소에 트립 두 가지 있습니다.

이제 해당 수치를 수행합니다. 모든 액세스 페이지를 한 번에 10, 000명의 사용자를 받았습니다 수 완료, 초당 1, 000개의 요청 수도 있게 됩니다. 모든 사용자가 됩니다 수 클릭하면 내용이 몇 초마다 때문에 매 초마다 웹 팜 이동하는 적어도 1, 000개의 및 대개 이상의 요청을 확인해야 합니다.

1, 000개 이상의 요청을 웹 팜 및 세션 저장소에 두 트립 웹 서버에 결과를 이동하는 모든 요청을 것입니다 경우를 가정해 봅니다. 웹 관점에서 세션 저장소에 2, 000명의 트립을 의미합니다. 로드 속도를 높일 수 있습니다 볼 수 있습니다. 이것은 한 곳에서 확장성 병목 현상이 발생할 수 있습니다.

페이지가 실행 중인 일부 응용 프로그램 데이터를 읽거나 쓸 할 상태에서 확장성 병목 현상이 발생할 수 있습니다. 이제 예제를 항공사 비행 가용성을 사용하십시오. 비행 한 위치에서 다른 응용 프로그램 데이터베이스로 여러 읽기 트립 인해 수 검색 페이지를 클릭할. 그런 다음 물론 사용자가 로그인을 비행 예약 필요한 데이터를 데이터베이스에 저장할 수 있도록. 이 데이터를 호출하면 " 응용 프로그램 데이터, " 데이터베이스에 저장됩니다. 그리고 여러 데이터 요소를 저장하는 데 여러 데이터베이스 트립 만들 저장 작업을 이 있습니다.

따라서 수 못했습니다, 결국 에서 wind 최대 수가 5, 10, 15, 또는 실제 사용자 요청 수를 20회 이상 데이터베이스 트립. 때문에 데이터베이스에서 스트레스 것입니다 훨씬 더 있으며 이 주 인해 지체가 생길 수 있습니다.

세 번째 확장성 병목 현상이 SOA (서비스 지향 아키텍처) 환경을 사용하고 응용 프로그램의 다른 서비스 계층 데이터 센터 내에서 또는 다른 데이터 센터에 될 수 있는 호출을 경우에 대한 제공됩니다.

일반적으로 서버 계층 아키텍처를 서버 팜 관련이 및 웹 응용 프로그램 아키텍처는 동일한 방식으로 확장 가능한 즉. 있지만 서비스 레이어를 고유한 데이터베이스를 의존하는 때문에 응용 프로그램에 대해 같은 확장성을 병목 현상이 있습니다.

있으므로 응용 프로그램의 종속성을 확장성 병목 차례대로 있는 해당 데이터베이스에서 종속성이 있는 다른 서비스에 1이고 체인의 경우에만 숙련된 링크로 강력한. 서비스 데이터베이스를 인해 배율을 조정하지 않습니다, 경우 응용 프로그램에서 조정하지 없습니다 ( 그림 1 참조).

그림 1 웹 팜 커질수록-데이터베이스 병목 현상이 됩니다.

실제로 되지 않습니다 데이터베이스에 있는 메인프레임 또는 관계형 데이터베이스를 있는지. 데이터 액세스 또는 데이터 저장소 단순히, 확장할 수 없으며 웹 기술을 확장성을 사용하여 따라 유지하는 것이 없습니다. 및 데이터 저장소에서 이러한 병목 현상을 방지할 배율 ASP.NET 응용 프로그램을.

이러한 문제 없음

데이터 저장소 배율을 이유는 없습니다? 이제 Microsoft는 세 가지 세션 상태 저장소 옵션을 먼저 누락: InProc, StateServer, 및 SqlServer. InProc 제한이 있습니다. 단일 서버, 단일 프로세스 환경에서 사용할 디자인된 인식하여 다중 서버 또는 multi-process ASP.NET 환경에서 작동하지 않습니다. 세션이 유지되지 않습니다.

어떤 일이 같습니다. 사용자가 한 서버에서 시작되고 세션이 있을 만들어집니다. 해당 응용 프로그램에서 해당 세션에 찾이 없습니다 부하 분산 다음 사용자가 다른 서버로 보내면, 사용자가 새로운 시작 및 다시 로그인할 전자 메일 확인 대기. 사용자가 작업을 클릭할 때마다 계속할 수 없습니다 됩니다 사용자가 로그인해야 할 자신이 것입니다. 응용 프로그램이 작동하지 않습니다.

한 가지 방법으로 이를 해결할 수 있습니다 " 스티커 세션 " 기능을 사용하면 항상 응용 프로그램이 서버에서 세션 찾이 됩니다 사용자 요청을 동일한 서버에 다시 경로를 사용하는 것입니다.

또한 서버에서 웹 가든에서 않은 만들어 InProc 제한 처리할 수도 있습니다. 웹 가든에서 사용자 응용 프로그램에는 동일한 서버에서 실행되는 여러 ASP.NET 작업자 프로세스를 경우입니다. 웹 가든을 사용하지 않으면 하나의 프로세스만 내용이 있고 있는 적어도 InProc 웹 팜에서 사용할 수 있습니다.

그러나 이러한 두 해결 경우 멀리 있는 이상적인, 스티커 세션 사용자 세션 길이가 일관된 없기 때문에 일부 서버의 로드가 다른 둘 이상의 증가합니다 때문에 주 확장성 병목 현상이 발생할 수 있습니다. 일부 사용자는 경우에만 1분, 20분 다른 로그인합니다. 일부 서버에서 세션 많이 얻을 수 하지만 거의 빈 또는 무료 또는 유휴 됩니다 이러한. 자세한 상자를 추가할 경우 수 있는 없습니다 반드시 향상시킬 처리량을.

또한 InProc 메모리 제한이 있습니다. ASP.NET 프로세스에서 모든 세션 메모리가 필요합니다. 세션 수를 늘리려면 것처럼 작업자 프로세스 메모리 요구 사항에 크게 증가합니다. 그러나 32비트 플랫폼에 작업자 프로세스의 1 GB 메모리 제한이 있고 문제가 준비되었습니다. 있는 한 GB 작업자 프로세스 메모리에 있는 다른 데이터 및 응용 프로그램 코드와 함께 맞는 초과하는 세션 데이터를 커질 수 없습니다. 따라서 InProc 병목 현상이 발생합니다. 더 많은 사용자를 합니다. 그리고 이러한 문제가 발생할 수 더.

StateServer 세션 상태를 ASP.NET 작업자 프로세스에서 별도의 프로세스에서 저장하지만 너무 제한이 있습니다. 모든 웹 서버에는 고유한 StateServer 또는 전용으로 별도의 상자 및 해당 상자에 완전히 상태를 유지할 수 구성할 수 있습니다.

첫 번째 옵션을 사용하여 문제는 여전히 스티커 세션을 사용해야 하는 것입니다. 세션을 만들 때마다 있는 항상 할 것이 돌아갑니다 준비되었습니다. 이 첫 번째 옵션은 경우에만 InProc 웹 가든 제한을 줄입니다. 다른 가득 동안에도 사용되는 가져올 않는 추가 상자를 수 남길 수 있는 스티커 세션 문제가 해결되지 않습니다. 사용자에게 net 효과가 자신의 세션 및 응답 시간이 매우 느려질 같습니다.

이 구성 옵션은 다른 단점은 경우 웹 서버에 있는 StateServer 아래로 있는 또한 Web server 상자에서 아래로 이동합니다 모든 세션이 손실될 수 있으므로 있는 것입니다. true 않는 분실한 웹 사이트의 모든 세션에 않지만 해당 상자에 저장된 세션 잃어버린 있으며 허용되는 것은 아닙니다. 원칙적으로는 않음 할 세션이 모두 손실됩니다.

StateServer 제공하는 다른 구성을 선택할 경우, 즉 전용 StateServer 상자 (더 이상 모든 웹 서버가 동일한 전용 상자를 이동합니다 때문에 스티커 세션을 사용할 필요가. 있지만 큰 문제가 없을 이제: 모든 웹 서버가 해당 상자에서 해당 세션을 가져오는 동안 경우 때문에 전체 웹 팜에 다운되었습니다 적이 있는 상자를 아래로 이동하는.

이게 모든 없습니다. 이 전용 StateServer 상자는 이상의 웹 서버 추가 및 초당 트랜잭션 확대 overwhelmed 가져옵니다. 따라서 신속하게 됩니다 확장성 병목 상태가. 따라서 확장성 문제는 경우 없습니다 해결할 StateServer, 함께 중 구성으로.

이제 Microsoft는 SQL Server 데이터베이스에 세션 상태를 저장하는 SqlServer 가져올 및 전용 StateServer 생각할 수 있습니다. 이것은 높은 트랜잭션 환경을 위한 Microsoft의 탁월한 데이터베이스 서버입니다. 이것은 데이터베이스 서버 클러스터를 만들 수 때문에 확장성이 있는 StateServer 아닌입니다.

SqlServer 구성에서 모든 웹 서버를 실제로 있는 전용 SqlServer 상자에 연결합니다 모든 세션에 저장된. 각 웹 서버의 전용 StateServer 상자에 연결된 것처럼 것은.입니다. 이 뒤에 개념은 SqlServer 있는 StateServer 아닌 확장성이 됩니다. 있지만 있는 StateServer 메모리 내 데이터 저장소에서 그에 따라 적합한 성능 있는 때문에 SqlServer State Server 빠른 아닙니다. 반면, SqlServer 메모리 내 데이터 저장소에서 않습니다. 해당 디스크 기반 데이터 저장소입니다. 따라서 커질 때 때문에 모든 데이터베이스 디스크에 보관됩니다 데이터베이스 전체를 보유할 있는 메모리가 부족합니다. 따라서 데이터베이스 디스크에 있는 영구 저장소에 해당 데이터를 저장합니다. 디스크 저장소 인해 SqlServer 성능은 같은 고속, 성능 드롭다운 결과지 않습니다.

SqlServer 여러 구성을 가져올 수 있습니다. 가장 일반적인, 독립 실행형 구성에서 모든 웹 서버에서 통신할 데이터베이스 서버가 하나만 있고 데이터베이스에 더 많은 로드를 넣으면 웹 팜 크기 증가 및 이상의 웹 서버를 추가합니다 ( 그림 2 참조).

그림 2 병목 현상 및 데이터베이스 또한 않은 fullyscalable ASP.NET 세션 계속

+ SqlServer 메모리 기초로 하지 않으므로 최대한 확장할 수 없으므로 확장성 문제가 있는 성능 문제가 있습니다. 최대 하드웨어 해당 상자에 CPU 추가하여 보다 강력한 하여 배율을 수 있지만 없습니다 계속 추가하려는 웹 팜 커질 때 이상의 데이터베이스 서버 상자에. 이동할 수 있습니다 수도 두 개 또는 두 세 서버로 한 SqlServer 수 있는 StateServer 이상 배율을지 않습니다 기능을 클러스터링 데이터베이스를 제공합니다 있도록 있지만 해당 제한 수도 있습니다.

다른 문제는 SqlServer 저장소에 있는 모든 세션에 단일 테이블에 있는 보관됩니다 있는 것입니다. 동시 액세스 및 세션 데이터의 동시 업데이트에 대한 잠금 경합 위로 배율을 즉시 확실한 됩니다. 초당 더 많은 트랜잭션 있으면 더 많은 잠금을 지연 합니다 때문에 한 테이블에 있는 모든 유지됩니다.

따라서 SqlServer 배율을 두 개 이상의 State Server, 그 성능 문제가 손 상태에서 충분히 배율을지 않습니다. 배율을 또한 이를 조정하지 않습니다 선형. 그러나 5-50 위해 100-서버 팜, 웹 팜 커질 수 간주되지 않습니다 웹 팜 원활하게 매우 커질 수 것으로, 데이터 액세스 않는지 않습니다 커질 포함한. 필자는 앞에서 설명한 것처럼 데이터베이스는 않는 커질 않는 이러한 데이터 저장소 액세스하는 중 있으므로 데이터베이스를 세션에 저장하는 주요 개선 만들기지 않습니다. 있는 상태 서버 환경을 통해 경우 증분 개선 것이.입니다. 또한 한 SqlServer 세션 데이터 경우와 응용 프로그램 데이터가 아니라 병목 현상이 됩니다. 따라서 데이터베이스 서버를 않는 세션 또는 응용 프로그램 데이터에 대한 확장할 수 없습니다.

다음 응답 무엇일까요?

해결책은 메모리 저장 메커니즘을 매우 빠르고, 한 StateServer 같이 빠른 수 있습니다. 그러나 거의 선형 확장 수 있어야 합니다. 선형 확장성을 있는 서버를 추가할 때 수 있는 거의 곱하여 용량을 의미합니다. 예를 들어, 하나의 상자가 초 당 10, 000개의 트랜잭션을 처리할 경우 두 번째 상자에서 추가할 합니다 제공합니다 두 번째 총 단위 20, 000개의 트랜잭션을 가깝게. 그러나 참고 있는 " 거의 선형 " 않습니다 의미가 정확히 20,000 (19,000 수 않고 않습니다, 12,000 또는 15,000. 우리는 필요한 이는: 거의 지속적으로 증가할 수 있는 저장소 및 그 합니다 메모리에 있을 수도.

이러한 두 요구를 인해 다른 요구 사항이 및 해당 장기 위한 영구 저장소에 대한 않은 통신하는 우리는 있습니다. 동안에는 메모리 저장소 항상 임시 파일과 임시 데이터베이스에 장기 저장 위한 것입니다. 있지만 우리 필요한 임시 있습니다. 전용 응용 프로그램 가장 있는 수도 몇 주 또는 몇 일 몇 시간 동안 사용자 세션 동안 또는 아마도 이 임시 저장소에 데이터를 저장해야 합니다. 다음 항상 여기서 우리는 수 데이터를 로드할 에서 다시 데이터베이스에 있는 영구 마스터 저장소에 있기 때문에 데이터를 즉시 이동할 수 있습니다.

모든 염두에 이, 우리가 생각할 있습니다 " 분산 캐시에 " 위의 다르게 이점을 제공하므로 일반적인 찼습니다 개념을 라는 저장소 메커니즘을 있으므로 같이 그림 3 보여 줍니다.

그림 3 데이터베이스 서버의 사용량을 relieving 분산 캐시

분산 캐시에 있는 경우-메모리, 빠르고, 것이 설계되었습니다 상당히 선형 증가 배포하려면 캐싱 토폴로지를 라고도 하는 올바른 배포 메커니즘을 경우에는 특히 있으므로

분산 캐시 높은 성능과 선형 확장성을 제공해야 합니다 하고 메모리에 존재하는 이후 있으므로 경우 모든 컴퓨터 아래로 이동합니다 복제 제공해야 이를 합니다 (해당 컴퓨터 메모리에서 사용할) 를 다른 컴퓨터로 데이터를 갖게 되며 모든 잃을 위험이 없습니다. 복제 제공하고 둘 이상의 다른 위치에 있는 같은 데이터의 복사본을 다른 상자를 이렇게 통해 데이터 저장소 기간 시간 최대 100 % 얻을 수 있다는.

분산 캐시 .NET 개체 또는 Java 개체를 저장하는 또는, 해당 사항, 다른 데이터와 같은 XML 문서를. 준비된 형식으로 데이터를 저장합니다. 테이블 및 행 및 기본 키와 외래 키를 데이터베이스에 있는 개념이 있지. 프로그래머가 있는 분산 캐시는 기본적으로 HASH 테이블을 키 및 각 키 값이 없고 값을 개체인. 키를 알고 있어야 하며 키를 기준으로 원하는 개체가 페치할 수 있습니다. 이는 하나의 논리 캐시 여러 서버에 걸쳐 있을 수 있습니다. 캐시 클러스터 크기가 커질 수 동시에 서버를 추가할 수 있으며 모든 중지하지 않고 캐시 클러스터를 축소하려면 동시에 상자에 제거할 수 있습니다.

토폴로지 캐싱

유효 캐시 제공하는 다양한 토폴로지에 복제됩니다 분할된, 복제 및 분할, 혼합 및 클라이언트 또는 로컬 캐시. 다양한 사용량, 캐시 매우 유연한 만드는 다른 캐싱 토폴로지에 할 것입니다. 복제 토폴로지 복제하는 캐시에 여러 번, 여러 번 방법에 따라 합니다 ( 그림 4 참조). 읽기 많이 캐시 사용 있지만 업데이트가 많이 없습니다 있는 경우에 위한 것입니다.

그림 4 복제된 캐시는 읽기 많이 사용 이상적인

분할된 캐시는 캐시되도록 하는 업데이트 많이 또는 트랜잭션 데이터의 확장성이 토폴로지를입니다. ASP.NET 세션 데이터를 매우 트랜잭션 수 있습니다. 모든 웹 요청에 대해 앞에서 설명한 것처럼 세션은 한 읽기 및 수와 읽기 및 쓰기 있습니다 한 번 업데이트할 것입니다.

분할 토폴로지 뛰어난 위치를 업데이트를 수행해야 횟수 만큼 최소한 읽기, 작업을 수행하는 것처럼 환경에서는 또는 아주 가까이 있는 경우 ( 그림 5 참조) 이 토폴로지의 캐시에 분할됩니다. 더 많은 캐시 서버를 추가할 수 캐시를 더 것입니다 거의 한 N번째 방식으로 분할된 (N 노드 수를 의미합니다) 캐시의 경우 각 서버에 저장된 캐시.

그림 5 A 분할된 캐시에 쓰기 많이 사용 적합합니다

세 번째 토폴로지가 분할 및 복제된 버전을 혼합입니다. 캐시 파티션을 있으며 한 번에 모든 파티션을 복제할 수 있습니다. 따라서 두 자리매김하기 최상의 얻을 수. 수 분할 및 증가, 더한 데이터가 손실되지 않도록 가용성을 복제할 수 있습니다 ( 그림 6 참조).

그림 6 파티션 복제본을 캐시를 안정성 함께 write-intensiveusage 적합합니다. .

분할 및 분할된 복제 혼합 토폴로지 도움을 선형 확장성 측면에서 캐시를 커질 수 있습니다.

클라이언트 또는 로컬 캐시 응용 프로그램 서버에서 위치합니다 네 매우 유용한 토폴로지를 않습니다. 캐시의 이 형식이 매우 응용 프로그램이 가깝게 형식이고 InProc 경우에도 사용할 수 있습니다. 일반적으로 사용자의 실제 대규모 분산 캐시의 작은 하위 있고 대로 해당 시점의 응용 프로그램을 갖고 않은 요청하는 기반으로. 원하는 경우 응용 프로그램 요청의 복사본은 클라이언트 캐시에 보관됩니다. 응용 프로그램에서 동일한 데이터를 사용하려는 경우 다음에 자동으로 찾습니다 해당 클라이언트 캐시에. 분산 캐시에 별도의 캐싱 서버나 캐시 서버 클러스터 네트워크를 자주 때문에 사용하여 출장 있는 경우에도 저장할 분산 캐시를 이동할 않아도. 클라이언트 캐시를 추가 성능 및 확장성 높임을 제공합니다.

분산 캐시를 사용하여 동기화된 클라이언트 캐시의 데이터는 유지해야 합니다. 같은 데이터를 분산 캐시에 변경되고 분산 캐시 변경 클라이언트 캐시를 동기화할 수 있습니다. 이 기능은 중요한 측면은 — 바로 완전히 끊어진 있는 로컬 캐시를 사용할 않으려면. 데이터 무결성 문제 때문에 수용할 수 있는 InProc 캐시 해당하는 준비되었습니다. 동기화되지 가져오는 같은 데이터 여러 복사본을 합니다.

다른 선택

사용할 여러 분산 캐싱 기능을... 지정하고, 같이 대부분의 상황에서 사용 가능한 솔루션을 더 제한된 기능 집합을 동안 상업용 것을 많은 옵션과 기능을 제공합니다.

뛰어난 성능, 확장성 및 높은 수준의 가용성 에서 외에 효율적인 분산 캐시 키 몇 가지 기능이 새로 및 마스터 데이터 원본을 사용하여 동기화된 캐시를 유지, 여부를 데이터베이스 또는 메인프레임 포함해야 합니다. 절대 시간 또는 " 슬라이딩 시간 " 라는 어떤 사용자의 될 수 있는 자동 만료 수행할 알 수 있도록 캐시 만료 옵션을 가집니다. 기본적으로 유휴 시간 점은, 를 데이터를 사용하는 다른 이를 자동으로 만료되었습니다.

캐시 다양한 데이터 간의 관계를 관리할 수도 합니다. 대부분의 데이터가 관계형입니다. 예를 들어, 고객 얻은 지금까지 경우에는 해당 고객에 대한 주문을 고객 데이터 및 주문 데이터를 사이의 관계를 있으므로 있습니다. 고객 및 주문 데이터 및 실수로 고객 데이터 캐시에서 삭제할 캐시 순서를 자동으로 삭제할 수 경우 감지를 만듭니다. 고객 데이터 캐시에서 제거할 또는 영구적으로 삭제됩니다 알고 이 인스턴스의 안 함. 영구적으로 이를 삭제한 다음 경우에 순서가 또한 잘못된 이제 순서를 유효한 고객의 수 있기 때문에입니다.

캐시에 있는 관리해야 관계 비슷한 종류가 다른입니다. 캐시 않는, 응용 프로그램이 계속 권한이 다음 추적 및 됩니다 매우 번거로운. 매우 유용한 ASP.NET Microsoft 캐시 개체는 " 캐시 종속성을 개념은. " 호출됩니다. 캐시된 항목을 다른 따라 달라집니다. 해당 캐시된 항목의 적이 캐시에서 제거될 또는 업데이트된 경우에도, 첫 번째 캐시 항목이 아니라 제거됩니다. 이 관계형 데이터 캐시 모든 캐시의 사용할 연결해야 하는 강력한 캐시 종속성을 개념입니다.

데이터베이스를 동기화할 캐시에 대한 다른 중요한 기능이 있습니다. 일반적으로 여러 응용 프로그램에서 데이터베이스가 공유됩니다. 캐시를 사용하여 응용 프로그램에 하나만 데이터베이스를 업데이트하는 경우 있이 필요가 없습니다 데이터베이스 동기화 기능을. 하지만 데이터베이스가 공유, 공용 저장소에 있으므로 해당 응용 프로그램을 캐시를 사용하지 않는 경우에 따라 타사 응용 프로그램이 다른 응용 프로그램에서 데이터베이스에 있는 데이터를 업데이트하는 매우 자주. 이러한 경우에도 않을 .NET 응용 프로그램을 수 있습니다. 타사 응용 프로그램 수 있지만 데이터베이스에서 업데이트할 제어할 수 없습니다. 따라서 응용 프로그램 외부에서 데이터베이스를 업데이트할 수 있습니다 있지만 일부 데이터베이스에서 업데이트된 데이터를 또한 캐시된 경우에 있도록 합니다. 따라서 캐시를 동기화할 수 있습니다. 없습니다 알 수 때마다 있는 데이터가 더 이상 데이터베이스에 있는 동일한. 캐시에서 데이터를 제거할 열과 수도 데이터베이스의 최신 복사본을 경우에도 다시 합니다. 데이터베이스 서버 또는 데이터베이스 폴링 캐시에서 발생한 이벤트를 통해 데이터베이스 동기화를 수행할 수 있습니다. 이벤트는 이상의 실시간 과정 중 폴링 있으며 약간의 지연이. 있지만 폴링 많은 데이터가 변경되는 경우 보다 효율적인 수 있습니다.

이벤트 알림이 중에서 가장 중요한 기능은 효과적인 분산 캐시에 있어야 합니다. 캐시 여러 응용 프로그램 간에 및 여러 사용자 간에 응용 프로그램 내에서 경우에도 자주 공유됩니다. 따라서 캐시에 캐시된 개체가 업데이트 또는 제거할 등 대비하여 이벤트 알림 메커니즘을 사용해야 합니다. 응용 프로그램에서 동일한 데이터를 사용하는 경우 알리지 않도록 데이터베이스를 때나 자체를 캐시에서 새 복사본을 다시 로드할 수 있습니다 할 수 있습니다. 여러 사용자나 캐시를 통해 여러 응용 프로그램에서 간의 공동 작업 알림 메커니즘을 향상시킵니다.

Real World

IT 관리 데이터베이스와 관련된 성능 문제를 직면합니다 및 병목 현상 의 경우 개발자가 보고할 수 있도록 lucky 경우에는 이러한 수 있습니다. 시도 이를 해결할 수. 그러나 개발이 아닙니다 사내 항상. 종종 살고 있는 및 타사 응용 프로그램을 관리할 수 있습니다.

어떤 경우이든 가장 개발자가 따라 필요가 있으므로 병목 현상 및 turbo 무료 응용 프로그램에서 ASP.NET 세션 저장소 사용하는 것입니다 열 분산 캐싱을 구현하는 시작하려면 배치합니다. 없는 프로그래밍 내용이 관련된. 것이 메모리 분산 캐시를 사용하여 기존 세션 저장소 대체하는 간단한 문제입니다. 또한 ASP.NET 세션 저장소에 대한 분산 캐시를 구현하는 수 성능 및 확장성, 계산 이점을 볼 기회가 제공하며 응용 프로그램 데이터에 대한 동일한 작업을 수행할 것인지 여부를 결정할 수 다음.

확장성 개선 발생하면 프로덕션 저장소 캐시 분산 실행해야 할 하나를 수 있고 테스트 환경에서 해당 로드를 시뮬레이션할 수 할 수 있습니다. 프로덕션 환경에서 분산 캐시에 넣으면 전에 많은 로드를 시뮬레이션할 수 테스트 환경에서 스트레스 테스트를 수행하는 데 도움이 QA 액세스할 수 있습니다. 대부분의 IT 관리자가 편리하게 넣으면 분산 캐시에 프로덕션 환경에서 했습니다 테스트한 것이 먼저 자신의 QA 환경에서 한 경우에도 동일한 양의 로드 시뮬레이션할 수 없습니다. 됩니다 않을 것입니다. 따라서 시작할 수 있는 좋은 위치가 준비되었습니다.

분산 캐시를 사용하여 실행 있다면 한 있고 해당 이점을 reaping 수 공유할 수 사용자의 새 ASP.NET 세션 성능 및 확장성 결과에 사내 또는 타사-공급업체 개발 팀과 함께. 직접 하드 증명이 분산 캐시에 있는 응용 프로그램 데이터를 캐시할 때 있습니다 영역을 분석할 개발 팀이 요청할 수 있습니다.

대부분의 경우 많은 더욱 높일 단순히 ASP.NET 세션 저장소 분산 캐시를 사용하는 것보다 및 응용 프로그램 데이터 캐싱 더 높임 제공합니다. 개발자가 업데이트될 때 보다 자주 읽을 수 있는 모든 데이터 요소를 식별하는 수 있어야 합니다. 고객, 주문 같은 같은 경우에도 트랜잭션 데이터를 캐싱, 좋은 후보 됩니다 만료되는 전에 몇 분 동안 캐시에 남아 해당 경우에도. 시간 이 짧은 기간 내에 데이터를 수 수 다시 여러 번 읽고 이 rereading 캐시 및 데이터베이스에 있는 경우 해당 데이터베이스의 읽기 로드가 많은 됩니다 때문입니다.

그러나 개발자가 응용 프로그램 데이터 캐시할 수 분산 캐시에 API 호출을 약간의 프로그래밍 작업을 수행할 수 있어야 살펴보겠습니다 이러한. 매우 간단한 것입니다. 해당 응용 프로그램에 데이터베이스에서 데이터를 페치합니다 할 때마다 캐시를 먼저 확인해야 합니다. 캐시에서 데이터가 있는 데이터 캐시에서 수행되지 않습니다. 그렇지 않은 경우에는 응용 프로그램이 데이터베이스에서 데이터를 페치합니다, 캐시합니다 추가되며 그런 다음 사용자에게 제공합니다. 이렇게 이 하면 데이터 됩니다 찾을 수 캐시에 읽을 때. 마찬가지로 데이터베이스의 데이터가 수정될 때마다 해당 또한 업데이트해야 합니다 캐시에. 수행하고, 캐시에 여러 서버에서 대기 경우 이를 합니다. 따라서 수 동기화되도록 자동으로 있는지 응용 프로그램에서 웹 팜에 있는 실행되면 동일한 캐시 데이터를 팜의 모든 서버에서 액세스할 수. 자세한 내용은 다음 항목에 대한 보다 나은 확장성 분산 캐시를 사용하는 응용 프로그램을 개발하는 방법에 대한 MSDN Magazine의 7월 문제가 예정된 내 문서를 찾습니다.

Iqbal 칸의 직위가 및 기술 Evangelist 중 Alachisoft, NCache 제공하는 회사 (업계 배포되는 .NET 캐시 성능 및 엔터프라이즈 응용 프로그램의 확장성을 높이는 선행 사용자의. Iqbal은 1990년 있는 경우 MS 인디애나 University, Bloomington, Computer Science 받은. 문의 사항이 있는 도달할 수 있습니다. iqbal@alachisoft.com.