SharePoint에서 개체 캐시 사용
이 문서에서는 SharePoint Server 2013 온-프레미스에서 개체 캐시를 사용하는 것과 Microsoft 365의 SharePoint에서 개체 캐시를 사용하는 것의 차이점을 설명합니다.
SharePoint 배포에서 개체 캐시에 의존하는 경우 상당한 부정적인 영향이 있습니다. SharePoint의 개체 캐시에 대한 종속성이 있으면 페이지의 안정성이 저하됩니다.
Microsoft 365 및 SharePoint Server 2013 개체 캐시의 SharePoint 작동 방식
SharePoint Server 2013이 온-프레미스에서 호스트되면 고객에게 개체 캐시를 호스트하는 프라이빗 프런트 엔드 웹 서버가 있습니다. 즉, 캐시는 한 고객 전용이며 사용 가능한 메모리의 양과 개체 캐시에 할당된 메모리의 양에 의해서만 제한됩니다. 온-프레미스 시나리오에서는 한 명의 고객만 제공되므로 프런트 엔드 웹 서버에는 일반적으로 사용자가 동일한 사이트에 대한 요청을 반복해서 수행할 수 있습니다. 즉, 캐시가 빠르게 가득 차서 사용자가 정기적으로 요청하는 목록 쿼리 결과 및 SharePoint 개체로 가득 차 있습니다.
따라서 사용자가 페이지를 두 번째로 방문할 때 페이지 로드 시간이 향상됩니다. 동일한 페이지의 최소 4개 로드 후 페이지는 모든 프런트 엔드 웹 서버에 캐시됩니다.
반면 Microsoft 365의 SharePoint에는 더 많은 서버뿐만 아니라 더 많은 사이트도 있습니다. 각 사용자는 캐시가 채워지지 않은 다른 프런트 엔드 웹 서버에 연결할 수 있습니다. 또는 캐시가 서버에 대해 채워지지만 해당 프런트 엔드 웹 서버의 다음 사용자가 다른 사이트의 페이지를 요청합니다. 또는 다음 사용자가 이전 방문과 동일한 페이지를 요청하더라도 캐시에 해당 페이지가 없는 다른 프런트 엔드 웹 서버에 부하가 분산됩니다. 이 마지막 경우 캐싱은 사용자에게 전혀 도움이 되지 않습니다.
다음 그림에서 각 점은 사용자가 요청하는 페이지와 캐시된 위치를 나타냅니다. 다른 색은 SaaS 인프라를 공유하는 다양한 고객을 나타냅니다.
다이어그램에서 볼 수 있듯이 지정된 사용자가 캐시된 버전의 페이지로 서버에 충돌할 가능성은 희박합니다. 또한 처리량이 많고 서버가 여러 사이트 간에 공유되므로 캐시가 오래 지속되지 않습니다. 캐싱을 사용할 수 있는 공간이 너무 많기 때문입니다.
이러한 모든 이유로 캐시된 개체를 가져오는 사용자에게 의존하는 것은 SharePoint에서 양질의 사용자 환경 및 페이지 로드 시간을 보장하는 효과적인 방법이 아닙니다.
SharePoint에서 성능을 향상시키기 위해 개체 캐시를 사용할 수 없는 경우 대신 무엇을 사용해야 할까요?
SharePoint에서 캐싱을 사용하지 않아야 하므로 개체 캐시를 사용하는 SharePoint 사용자 지정에 대한 대체 디자인 방법을 평가해야 합니다. 이는 사용자에게 좋은 결과를 생성하기 위해 개체 캐싱에 의존하지 않는 성능 문제에 대한 접근 방식을 사용하는 것을 의미합니다. 이 내용은 이 시리즈의 다른 문서 중 일부에 설명되어 있으며 다음을 포함합니다.