WAN 환경에 맞게 Office SharePoint Server 최적화

아티클
06/16/2015

업데이트 날짜: 2009년 4월

적용 대상: Office SharePoint Server 2007

마지막으로 수정된 항목: 2015-03-09

이 문서의 내용

WAN에 대한 토폴로지 디자인
콘텐츠 크롤링 프로세스 최적화
WAN 가속기 및 기타 타사 도구
더욱 빠른 다운로드를 위한 페이지 디자인
WAN 환경에 맞게 캐싱 최적화

이 문서에서는 WAN(광역 네트워크) 환경에서 성능 향상을 위해 Microsoft Office SharePoint Server 2007 솔루션을 최적화할 수 있는 몇 가지 방법을 집중적으로 살펴봅니다.

WAN에 대한 토폴로지 디자인

특정 성능 또는 가용성 요구 사항에 맞게 최적화하기 위해 Office SharePoint Server 2007 팜에서 서버 역할을 융통성 있게 구성할 수 있습니다. WAN 환경에서는 서버 역할의 몇 가지 기술적 특성을 이해해야 합니다. 전체적인 성능 및 가용성 요구 사항에 대한 계획을 수립하는 것 외에도 이러한 특성을 이해하면 WAN 환경에 맞게 서버 팜 토폴로지를 최적화하는 데 도움이 될 수 있습니다.

콘텐츠 크롤링을 위한 토폴로지 최적화

기본적으로 Office SharePoint Server 2007에서는 모든 웹 서버를 사용하여 서버 팜에서 콘텐츠를 크롤링합니다. 서버 팜이 크롤링에 모든 웹 서버를 사용하도록 구성된 경우 인덱스 서버는 팜의 각 웹 서버에 요청을 보냅니다.

팜에서 콘텐츠를 크롤링하면 웹 서버에 큰 작업 부하가 걸립니다. 이로 인해 네트워크 트래픽이 급격히 증가하고 CPU와 메모리가 많이 사용될 수 있습니다. 팜에서 콘텐츠를 크롤링하면 네트워크에 사용자 요청보다 많은 트래픽이 유발될 수 있습니다. 이러한 네트워크 트래픽으로 인해 서버 팜에 있는 모든 웹 서버의 성능이 저하될 수 있으며, 이에 따라 SharePoint 사이트의 콘텐츠에 대한 사용자 요청에 응답하는 시간이 증가할 수 있습니다.

WAN 환경에서는 특히 500GB(기가바이트) 이상의 콘텐츠가 들어 있는 서버 팜을 크롤링하거나 WAN을 통해 콘텐츠를 크롤링하는 경우 콘텐츠 크롤링 전용 웹 서버를 구성하는 것이 좋습니다. 사용자 요청이 콘텐츠 크롤링의 영향을 받지 않게 하려면 네트워크 부하 분산 순환에서 전용 웹 서버를 제거합니다. 이 방법은 지역 팜의 사용량이 적은 시간(크롤링 작업을 예약할 가능성이 높은 시간)이 중앙 팜의 사용량이 가장 많은 시간과 일치하는 전역 환경에서 특히 중요합니다.

로컬 콘텐츠 크롤링 전용 웹 서버 구성

팜의 로컬 콘텐츠를 크롤링할 때 성능을 최대화하려면 인덱스 서버의 메모리 용량이 충분하여 두 역할을 모두 수행할 수 있는 경우 인덱스 서버를 크롤링 전용 웹 서버로 구성합니다.

다음 그림에서는 콘텐츠 인덱싱 전용 웹 서버를 사용하여 최적화된 팜을 보여 줍니다.

WAN 토폴로지의 SharePoint Server

인덱스 서버와 전용 웹 서버로 동일한 서버를 사용하면 콘텐츠를 크롤링할 때 인덱스 서버에서 다른 서버에 요청을 보낼 필요가 없습니다. 따라서 크롤링 성능이 향상되고 네트워크의 전체적인 트래픽이 감소합니다. 이렇게 할 수 없는 경우에는 서버 팜의 다른 서버를 사용할 수 있습니다.

다음 방법 중 하나를 사용하여 전용 웹 서버를 사용하도록 인덱서를 구성할 수 있습니다.

SharePoint 중앙 관리에서 Office SharePoint Server 검색 서비스를 구성합니다.
호스트 파일을 직접 편집합니다.

자세한 내용은 다음 리소스를 참조하십시오.

원격 팜 크롤링 전용 웹 서버 구성

지역 팜에 있는 콘텐츠를 크롤링할 때 지역 팜의 성능을 최대화하려면 지역 팜의 전용 웹 서버를 사용하도록 중앙 팜의 인덱스 서버를 구성합니다.

다음 그림에서는 콘텐츠 인덱싱 전용 웹 서버를 사용하여 각각 최적화된 두 지역 팜을 보여 줍니다.

지역 팜 1에는 웹 서버 역할 전용의 서버가 하나 있습니다. 중앙 팜과 지역 팜 1에서 모두 이 전용 웹 서버를 콘텐츠 크롤링에 사용합니다.
지역 팜 2는 인덱스 서버로도 배포된 웹 서버 역할을 사용하여 중앙 팜과 유사하게 구성되어 있습니다.

WAN에 대해 Office SharePoint Server 최적화

중앙 팜의 인덱스 서버는 중앙 팜의 웹 서버 역할을 사용하여 원격 팜의 콘텐츠를 크롤링하지 않습니다. 인덱스 서버가 원격 팜의 웹 서버와 직접 통신합니다.

앞의 그림에서 중앙 팜이 콘텐츠를 크롤링하고 있을 때 지역 팜도 동시에 크롤링하는 경우 다음과 같은 면에서 지역 팜 1 구성이 더 나은 성능을 제공합니다.

전용 웹 서버가 별도의 서버에 있기 때문에 지역 팜 1의 로컬 크롤링 성능이 향상됩니다. 따라서 중앙 팜은 인덱스 서버의 성능에 영향을 미치지 않습니다.
WAN을 통한 크롤링 시간이 향상됩니다. 지역 팜의 전용 웹 서버가 인덱스 서버와 함께 공유 서버에 있는 경우보다 응답 속도가 빠르기 때문에 크롤링 시간이 줄어듭니다.
중앙 팜의 인덱스 서버가 전용 웹 서버와 통신하기 때문에 중앙 팜의 크롤링 프로세스가 향상됩니다.

지역 팜 2에 표시된 토폴로지 구성을 구현하는 경우 겹치지 않도록 두 팜의 크롤링 프로세스를 예약하여 성능을 최적화할 수 있습니다.

원격 팜의 전용 웹 서버를 콘텐츠 크롤링에 사용하려면 호스트 파일을 직접 편집해야 합니다. 이때 원격 팜이 아니라 콘텐츠를 크롤링하는 팜의 호스트 파일을 편집해야 합니다.

중앙 팜이 지역 팜의 콘텐츠를 크롤링하는 글로벌 솔루션에서는 크롤링할 각 지역 팜의 각 웹 응용 프로그램에 대한 항목을 포함하도록 호스트 파일을 편집합니다. 호스트 파일의 항목에는 전용 웹 서버의 IP 주소와 웹 응용 프로그램의 이름이 차례로 포함됩니다. 예를 들면 다음과 같습니다.

10.10.10.4 TeamSites
10.10.10.4 MySites
10.10.10.4 Marketing
10.10.10.4 Sales

자세한 내용은 호스트 파일을 편집하여 크롤링을 위한 전용 프런트 엔드 웹 서버 구성(Office SharePoint Server 2007)을 참조하십시오.

쿼리 성능을 위한 최적화

사용자에 대한 쿼리 성능은 WAN 환경에서 Office SharePoint Server 2007을 배포할 때 주요 고려 사항입니다. 사용자가 쿼리를 실행하면 쿼리가 웹 서버에 전송됩니다. 웹 서버는 쿼리 서버와 통신하여 결과의 목록을 만든 다음 Microsoft SQL Server를 실행하는 컴퓨터와 통신하여 요약 텍스트, URL 및 보안 조정으로 결과의 목록을 확장합니다.

쿼리 결과를 반환하는 데 필요한 서버 간 통신의 경우 쿼리 성능을 최적화하도록 토폴로지를 구성할 수 있습니다. 서버 팜 내의 적은 최적화로 WAN을 통한 클라이언트 컴퓨터와 서버 간의 전체적인 성능이 향상될 수 있습니다.

가장 중요한 최적화는 이전 섹션에서 설명한 대로 콘텐츠 크롤링에 전용 웹 서버를 사용하는 것입니다. 이렇게 하면 웹 서버가 사용자 요청에 사용 가능하며 인덱싱 작업으로 오버로드되지 않습니다.

각각 다른 유형의 최적화를 제공하는 몇 가지 쿼리 역할 배포 옵션이 있습니다. 각 옵션은 쿼리 요청을 최적으로 처리하는 것과 로컬 네트워크에서 팜 서버 간의 네트워크 통신을 줄이는 것 사이의 균형점을 각기 다르게 설정합니다. 다음 표에서는 이러한 구성 옵션을 요약하고 각 옵션의 장단점에 대해 설명합니다.

구성	장단점
모든 웹 서버에 쿼리 역할 배포	팜에 있는 서버 간의 왕복 통신을 줄이기 위해 웹 서버에 쿼리 역할을 호스팅할 수 있습니다. 이에 따라 쿼리 성능이 최적화됩니다. 그러나 두 서버 역할이 동일한 서버에서 호스팅되기 때문에 웹 서버가 많이 사용되는 경우 웹 서버의 전체적인 성능이 영향을 받을 수 있습니다. 따라서 사용량이 가장 많은 시간에 사용자 요청을 처리할 수 있도록 충분한 웹 서버를 배포해야 합니다. 이 구성이 사용자에 대한 쿼리 성능을 최적화하지만 단점은 팜의 백 엔드에 있습니다. 인덱스 서버는 팜의 각 쿼리 서버에 인덱스 카탈로그를 전파합니다. 쿼리 역할이 여러 웹 서버에 배포된 경우 인덱스 전파 중에 서버 리소스가 많이 필요합니다.
하나 이상의 서버를 쿼리 역할 전용으로 사용	쿼리 역할을 호스팅하는 하나 이상의 전용 서버를 사용하면 이러한 서버가 사용 가능한 모든 리소스를 사용하여 쿼리 역할을 효율적으로 수행하도록 최적화됩니다. 일반적으로 이 구성에서는 더 적은 쿼리 서버를 배포하게 됩니다. 그러나 이 구성에는 웹 서버의 쿼리 요청을 처리하고 인덱스 전파 중에 콘텐츠 인덱스를 업데이트하기 위해 팜에 있는 서버 간의 왕복 통신이 더 많이 필요합니다.
동일한 서버에 쿼리 및 인덱스 역할 배포	쿼리 역할과 인덱스 역할을 동일한 서버에 배포할 수 있습니다. 이렇게 하면 인덱스 전파가 더 이상 필요하지 않기 때문에 팜 통신이 최적화됩니다. 그러나 이 구성에서는 쿼리 역할을 호스팅할 수 있는 서버 수가 한 서버로 제한됩니다. 이는 쿼리 역할이 인덱스 서버에 배포되는 경우 해당 인덱스 서버에서 팜의 다른 서버에 콘텐츠 인덱스를 전파할 수 없기 때문입니다.

모든 웹 서버에 쿼리 역할 배포

팜에 있는 서버 간의 왕복 통신을 줄이기 위해 웹 서버에 쿼리 역할을 호스팅할 수 있습니다. 이에 따라 쿼리 성능이 최적화됩니다.

그러나 두 서버 역할이 동일한 서버에서 호스팅되기 때문에 웹 서버가 많이 사용되는 경우 웹 서버의 전체적인 성능이 영향을 받을 수 있습니다. 따라서 사용량이 가장 많은 시간에 사용자 요청을 처리할 수 있도록 충분한 웹 서버를 배포해야 합니다.

이 구성이 사용자에 대한 쿼리 성능을 최적화하지만 단점은 팜의 백 엔드에 있습니다. 인덱스 서버는 팜의 각 쿼리 서버에 인덱스 카탈로그를 전파합니다. 쿼리 역할이 여러 웹 서버에 배포된 경우 인덱스 전파 중에 서버 리소스가 많이 필요합니다.

하나 이상의 서버를 쿼리 역할 전용으로 사용

쿼리 역할을 호스팅하는 하나 이상의 전용 서버를 사용하면 이러한 서버가 사용 가능한 모든 리소스를 사용하여 쿼리 역할을 효율적으로 수행하도록 최적화됩니다. 일반적으로 이 구성에서는 더 적은 쿼리 서버를 배포하게 됩니다.

그러나 이 구성에는 웹 서버의 쿼리 요청을 처리하고 인덱스 전파 중에 콘텐츠 인덱스를 업데이트하기 위해 팜에 있는 서버 간의 왕복 통신이 더 많이 필요합니다.

동일한 서버에 쿼리 및 인덱스 역할 배포

쿼리 역할과 인덱스 역할을 동일한 서버에 배포할 수 있습니다. 이렇게 하면 인덱스 전파가 더 이상 필요하지 않기 때문에 팜 통신이 최적화됩니다.

그러나 이 구성에서는 쿼리 역할을 호스팅할 수 있는 서버 수가 한 서버로 제한됩니다. 이는 쿼리 역할이 인덱스 서버에 배포되는 경우 해당 인덱스 서버에서 팜의 다른 서버에 콘텐츠 인덱스를 전파할 수 없기 때문입니다.

쿼리 성능을 위해 단일 팜을 최적화하는 방법 외에도 복수 팜 시나리오를 최적화하기 위한 몇 가지 옵션이 있습니다.

상위 팜이 하위 팜에 검색 서비스를 제공하는 팜 간 공유 서비스 시나리오에서 상위 팜에 전용 쿼리 서버를 배포하면 상위 팜이 상위 팜의 다른 사용자 옵션 성능에 영향을 미치지 않고 하위 팜의 검색 쿼리를 처리할 수 있습니다. 팜 간 공유 서비스 시나리오에서 하위 팜의 웹 서버는 상위 팜의 웹 서버를 통해 통신하지 않고 상위 팜의 쿼리 서버 및 데이터베이스 서버와 직접 통신합니다. 상위 팜이 하위 팜에 서비스를 제공하는 팜 간 공유 서비스는 WAN을 통해 지원되지 않습니다. 그러나 대규모 조직에는 서비스를 제공하는 상위 팜과 사이트 및 콘텐츠를 제공하는 하위 팜이 있는 중앙 사이트가 포함될 수 있습니다. 이 시나리오에서는 중앙 사이트에서 사용자에게 사이트와 콘텐츠를 제공하는 중앙 사이트의 하위 팜 성능에 영향을 미치지 않고 지리적으로 분산된 복수 팜 환경의 지역 팜에서 콘텐츠를 크롤링하도록 상위 팜을 구성할 수 있습니다.
중앙 팜이 지역 팜의 콘텐츠를 크롤링하는 지리적으로 분산된 복수 팜 환경에서는 다음과 같은 방식으로 서버를 구성하여 콘텐츠 크롤링과 쿼리 성능을 모두 최적화할 수 있습니다.
- 모든 팜의 인덱스 서버에 웹 서버 역할을 배포합니다. 네트워크 부하 분산 순환에서 이 서버를 제거하고 콘텐츠 크롤링에 이 전용 웹 서버를 사용하도록 상위 팜 크롤링 프로세스를 구성합니다.
- 각 팜에 있는 부하가 분산된 모든 웹 서버에 쿼리 서버를 배포합니다.

지리적으로 팜 서버 분리

서버 팜의 서버 간 통신에는 사용자 요청을 적절하게 처리하고 성능 병목 현상을 방지하기 위한 강력한 네트워크 연결이 필요합니다. 표준 네트워킹 요구 사항으로, 서버 팜의 모든 서버는 동일한 LAN(Local Area Network)의 동일한 데이터 센터에 있어야 합니다. WAN 링크로 연결되도록 팜 서버를 분리하는 것은 지원되지 않습니다.

이 지침 외에도 하나 이상의 웹 서버가 나머지 팜 서버와 지리적으로 다른 위치에 있을 수 있는 특정 요구 사항이 있습니다. 이 시나리오에서는 웹 서버가 다른 데이터 센터에 있지만 SQL Server를 실행하는 컴퓨터와 동일한 LAN에 연결됩니다.

참고

다음 지침은 이전에 문서화되지 않은 배포 시나리오에 대한 지원 요구 사항을 나타냅니다.
이 시나리오에 대한 지침은 임시적이며 추가 테스트 후 변경될 수 있습니다. 여기에서는 공식적으로 테스트된 지침이 제공될 때까지 테스트와 배포에 사용할 수 있는 일련의 지침을 제공합니다. 이러한 지침을 바탕으로 사용자 환경에서 테스트하고 품질과 성능의 임계값을 결정하십시오.
이 시나리오는 상업적으로 적당한 지원 방법으로 지원됩니다. 사용자 환경에서 추가 테스트나 결과를 통해 이 시나리오로 심각한 문제가 발생하는 것을 확인하면 웹 서버를 데이터베이스 서버와 더 가까운 곳으로 이동해야 합니다(이 방법으로 문제가 해결되는 경우).

이 배포 시나리오는 다음과 같은 경우에 임시 지원 요구 사항을 충족합니다.

웹 서버와 데이터베이스 서버 간의 네트워크 링크 대기 시간이 1ms 미만입니다. 이 대기 시간을 얻으려면 이상적으로 웹 서버가 데이터베이스 서버에서 10마일 이하 떨어진 곳에 있습니다. 대부분의 최적 네트워킹 구성에서는 드문 경우이긴 하지만 최대 100마일의 거리에서 1ms 미만의 대기 시간을 얻을 수 있습니다. 거리가 10마일에서 100마일 사이이면 네트워크 및 하드웨어 공급자에게 문의하여 대기 시간이 1ms 미만인 서비스 수준을 제공할 수 있는지 확인하십시오. 100마일이 넘는 거리로 팜 서버를 분리하는 것은 지원되지 않습니다. 동일한 팜의 서버를 호스팅하는 두 데이터 센터 간의 대기 시간을 측정할 때는 Ping 도구를 사용하여 원격 데이터 센터에 있는 웹 서버에서 기본 데이터 센터에 있는 데이터베이스 서버로의 대기 시간을 측정한 다음 왕복 결과를 2로 나눕니다.
웹 서버와 팜의 다른 서버 간의 트래픽을 처리하는 데 충분한 대역폭을 링크에서 사용할 수 있습니다.
공유 서비스에 기여하는 모든 서버 역할이 데이터베이스 서버와 동일한 데이터 센터에 있습니다. 이러한 역할에는 인덱스, 쿼리 및 Excel 서비스 역할이 있습니다.
팜의 모든 서버 컴퓨터가 동일한 네트워크 세그먼트에 있습니다. 데이터 계층에서 라우터의 스위칭이 없습니다. 사실상 물리적 계층에서 서버에 연결합니다. 라우터와 스위치는 서로 간의 네트워크 연결이 매우 빠른 경우에도 대기 시간을 증가시킵니다.
웹 서버에서 처리하고 있는 작업의 유형이 사용자 탐색 요청에 속하는 경우 Office SharePoint Server 2007에서 웹 서버와 데이터베이스 서버 간의 대기 시간을 허용합니다. 반면에 Stsadm 명령, 검색 크롤링 및 많은 웹 파트나 사용자 지정 웹 파트가 포함된 페이지는 만족스럽게 처리되지 않을 수 있습니다.
서버 팜에 있는 서버는 해당 표준 시간대를 벗어나지 않습니다. 서버 팜의 모든 서버 컴퓨터는 동일한 표준 시간대로 동기화되어야 합니다.

콘텐츠 크롤링 프로세스 최적화

크롤링 프로세스를 예약하고 구성하는 방법은 성능과 안정성에 영향을 미칠 수 있습니다. WAN을 통한 크롤링을 개선하기 위해 다음과 같은 프로세스를 최적화할 수 있습니다.

콘텐츠 원본에 대한 크롤링 조정
크롤링 빈도 구성과 전체 및 증분 크롤링 조정
크롤링 설정 구성

콘텐츠 원본에 대한 크롤링 조정

중앙 팜이 WAN 링크를 통해 지역 팜의 콘텐츠를 크롤링하는 전역 환경에서는 콘텐츠 원본이 예약하고 관리할 수 있는 콘텐츠 단위를 나타내기 때문에 콘텐츠 원본에 대한 계획을 수립해야 합니다.

다음 작업을 수행해야 할 경우에 검색할 콘텐츠 원본을 추가하십시오.

여러 가지 유형의 저장소 크롤링
다른 저장소와 다른 일정에 따라 일부 저장소 크롤링
크롤링되는 콘텐츠의 양 제한 또는 증대

이러한 각 이유는 WAN을 통한 콘텐츠 크롤링을 최적화할 때 요인으로 포함될 수 있습니다. 최소한 지역 팜마다 각기 다른 콘텐츠 원본을 만듭니다. 이렇게 하면 팜의 사용량이 적은 현지 시간과 유지 관리 일정에 따라 각 지역 팜의 크롤링을 예약할 수 있습니다.

또한 다음 기준에 따라 단일 지역 팜에 대한 여러 가지 콘텐츠 원본을 만듭니다.

자주 크롤링할 콘텐츠(통합 콘텐츠 등)나 자주 크롤링하지 않을 콘텐츠(게시된 콘텐츠 등)에 대한 별도의 콘텐츠 원본을 만듭니다.
정기적으로 게시되는 콘텐츠에 대한 별도의 콘텐츠 원본을 만듭니다. 예를 들어 특정 사이트 집합의 콘텐츠가 금요일에만 업데이트되는 경우 콘텐츠 업데이트와 크롤링 일정을 동기화하기 위해 별도의 콘텐츠 원본을 만들 수 있습니다.
지역 팜의 사용량이 가장 많은 시간 동안 WAN 링크를 통해 크롤링할 수 있는 콘텐츠의 양에 따라 콘텐츠 원본을 만듭니다. 예를 들어 대규모 저장소를 매주 한 번씩 크롤링하려는 경우 야간에 성공적으로 크롤링할 수 있는 5-7개의 콘텐츠 청크로 저장소를 나눈 다음 한 주 동안 크롤링 작업을 일정하게 나누어 처리할 수 있습니다.
Office SharePoint Server 2007 사이트 외부의 콘텐츠에 대한 별도의 콘텐츠 원본을 만듭니다. Office SharePoint Server 2007과 Windows SharePoint Services 3.0에서는 변경 로그에 ACL(액세스 제어 목록)에 대한 업데이트를 비롯한 변경된 개체가 기록됩니다. 변경 로그를 통해 변경된 콘텐츠만 증분 크롤링하여 콘텐츠 원본을 다시 크롤링하는 데 필요한 시간을 크게 줄일 수 있습니다. 외부 원본에 저장된 콘텐츠는 증분 크롤링할 수 없습니다. 따라서 이러한 콘텐츠 원본에 대한 크롤링 프로세스는 별도로 관리해야 합니다. 자세한 내용은 변경 로그 (영문)(https://go.microsoft.com/fwlink/?linkid=106007&clcid=0x412)를 참조하십시오.

크롤링과 콘텐츠 원본의 계획을 수립하는 방법에 대한 자세한 내용은 콘텐츠 크롤링 계획(Office SharePoint Server)을 참조하십시오.

크롤링 빈도 구성과 전체 및 증분 크롤링 조정

이전 섹션에서 설명했듯이 별도의 콘텐츠 원본을 만드는 기본적인 이유는 다양한 일정으로 콘텐츠를 크롤링할 수 있게 하기 위해서입니다. 이는 콘텐츠가 대기 시간이 긴 WAN 링크를 통해 크롤링되는 환경에서 특히 중요합니다. 지역 팜에 대한 크롤링 작업을 예약하는 경우 다음과 같은 요소를 고려하십시오.

지역 팜의 예약된 가동 중지 시간 및 사용률 최대 시간
콘텐츠가 변경되거나 업데이트되는 빈도
WAN 링크의 대역폭 가용성 및 대기 시간. WAN 링크를 사용하는 다른 프로세스를 고려해야 합니다.

Office SharePoint Server 2007과 Windows SharePoint Services 3.0에서는 각 콘텐츠 원본에 대해 전체 크롤링을 수행할 시간과 증분 크롤링을 수행할 별도의 시간을 지정할 수 있습니다. 먼저 특정 콘텐츠 원본에 대해 전체 크롤링을 실행한 후에만 증분 크롤링을 실행할 수 있습니다. 크롤링되지 않은 콘텐츠에 대해 증분 크롤링을 선택하는 경우 전체 크롤링이 수행됩니다.

WAN 환경에 대한 크롤링 일정을 계획하는 경우 다음과 같은 최상의 방법을 고려하십시오.

WAN 링크의 사용이 시간에 따라 균등하게 배분되고 WAN 링크가 포화 상태가 되지 않도록 크롤링 일정을 적절히 배치합니다.
필요한 경우에만 전체 크롤링을 예약합니다. 전체 크롤링은 증분 크롤링보다 낮은 빈도로 실행하는 것이 좋습니다.
콘텐츠를 호스팅하는 서버가 사용 가능한 상태이고 서버의 리소스 사용량이 적은 시간에 각 콘텐츠 원본에 대한 증분 크롤링이 수행되도록 일정을 계획합니다.
Office SharePoint Server 2007과 Windows SharePoint Services 3.0에서 서비스 팩을 적용하거나 데이터베이스를 복원하는 등의 관리 변경 사항이 발생하면 다음에 정기적으로 예약된 크롤링 중에 전체 크롤링이 자동으로 수행됩니다. 전체 크롤링이 필요한 관리 변경 사항의 경우 계획된 전체 크롤링 일정 바로 전에 수행되도록 예약합니다. 예를 들어 추가 전체 크롤링이 필요하지 않도록 다음에 예약된 전체 크롤링 전에 크롤링 규칙을 만드는 작업을 예약하는 것이 좋습니다. 전체 크롤링을 필요로 하는 관리 변경 사항에 대한 자세한 내용은 콘텐츠 크롤링 계획(Office SharePoint Server)의 "전체 크롤링을 수행하는 이유"를 참조하십시오.

중요

Microsoft Office Servers 인프라 업데이트를 적용한 후 이후 업데이트와 데이터베이스 복원이 발생하면 전체 크롤링이 자동으로 수행되지 않습니다. 따라서 이후 업데이트를 적용하거나 데이터베이스를 복원하는 경우 검색 기능은 크롤링 규칙에 정의된 정기 일정에 따라 크롤링을 계속 수행합니다. 자세한 내용은 콘텐츠 크롤링 계획(Office SharePoint Server)을 참조하십시오.

개별 지역 사이트에서의 콘텐츠 크롤링에 적용되는 이러한 최상의 방법 외에도 중앙 팜의 전체적인 크롤링 일정이 인덱스 서버의 크롤링 용량을 초과하지 않게 해야 합니다. 인덱스 서버에서 동시에 크롤링할 수 있는 성능을 고려하여 동시 크롤링을 계획합니다. 인덱스 서버 및 콘텐츠를 호스팅하는 서버의 성능에 따라 크롤링을 중복하여 실행할 수 있는 정도가 다릅니다. 시간이 지남에 따라 각 콘텐츠 원본의 일반적인 크롤링 기간을 파악하게 되면 크롤링 예약 전략을 효과적으로 개발할 수 있습니다.

크롤링과 콘텐츠 원본의 계획을 수립하는 방법에 대한 자세한 내용은 콘텐츠 크롤링 계획(Office SharePoint Server)을 참조하십시오.

크롤링 설정 구성

WAN 설정에 대한 몇 가지 크롤링 설정을 최적화하여 크롤링 작업의 안정성을 높일 수 있습니다. 다음과 같은 설정을 사용할 수 있습니다.

검색 시간 제한 설정
크롤러 영향 규칙

검색 시간 제한 설정

팜 관리자는 서버가 다른 서비스에 연결하는 동안 대기하는 시간과 콘텐츠 요청이 승인되기를 대기하는 시간을 지정할 수 있습니다. WAN 링크를 통해 크롤링되는 콘텐츠 원본을 추가하는 경우 링크의 전체적인 대기 시간에 따라 사전 조치로 시간 제한 설정을 늘립니다. WAN 링크를 통한 콘텐츠 크롤링의 실제 성능에 따라 언제든지 시간 제한 설정을 조정할 수 있습니다.

다음 절차에 따라 Office SharePoint Server 검색 서비스의 시간 제한 설정을 지정합니다.

시간 제한 설정 지정

중앙 관리의 응용 프로그램 관리 탭에 있는 검색 섹션에서 검색 서비스 관리를 클릭합니다.
검색 서비스 관리 페이지의 팜 수준 검색 설정 섹션에서 팜 수준 검색 설정을 클릭합니다.
팜 수준 검색 설정 관리 페이지의 제한 시간 설정 섹션에서 다음을 수행합니다.
- 연결 시간(초) 상자에 다른 서비스에 연결하는 동안 서버에서 대기할 시간(초)을 입력합니다.
- 요청 승인 시간(초) 상자에 다른 서비스가 서비스에 대한 연결 요청을 승인할 때까지 서버에서 대기할 시간(초)을 입력합니다.
확인을 클릭합니다.

크롤러 영향 규칙

크롤러 영향 규칙은 한 번에 요청되고 크롤링되는 문서 수를 제어하는 방법을 제공합니다. 관리자는 크롤러 영향 규칙을 사용하여 크롤링 작업이 WAN 링크에 미치는 영향을 관리할 수 있습니다.

각 크롤러 영향 규칙에 대해 단일 URL을 지정할 수도 있고, URL 경로에 와일드카드 문자를 사용하여 규칙을 적용할 URL 블록을 포함할 수도 있습니다. 그런 다음 지정된 URL에 수행되는 동시 페이지 요청 수를 지정하거나, 한 번에 한 문서만 요청하고 요청 사이에 선택한 시간(초)을 기다리도록 선택할 수 있습니다.

초기 배포 중에 크롤링된 콘텐츠의 최신성을 보장할 정도로 빈번하게 충분한 콘텐츠를 크롤링하면서도 가능한 한 효율적으로 WAN 링크를 사용하도록 크롤러 영향 규칙을 설정합니다. 이후 운영 단계에서 사용자의 경험과 크롤링 로그의 데이터에 따라 크롤러 영향 규칙을 조정할 수 있습니다.

다음 절차에 따라 크롤러 영향 규칙을 추가합니다.

크롤러 영향 규칙 추가

중앙 관리의 응용 프로그램 관리 탭에 있는 검색 섹션에서 검색 서비스 관리를 클릭합니다.
검색 서비스 관리 페이지의 팜 수준 검색 설정 섹션에서 크롤러 영향 규칙을 클릭합니다.
크롤러 영향 규칙 페이지에서 규칙 추가를 클릭합니다.
크롤러 영향 규칙 추가 페이지의 사이트 섹션에 있는 사이트 상자에 이 크롤러 영향 규칙과 연결할 사이트 이름을 입력합니다.

참고

URL을 입력할 때 http:// 또는 file:// 등의 프로토콜은 제외해야 합니다.
요청 빈도 섹션에서 다음 옵션 중 하나를 선택합니다.
- 한 번에 지정된 문서 수까지 요청하고 요청 사이에 대기 안 함. 이 옵션을 선택하는 경우 동시 요청 수 목록에서 이 URL을 크롤링할 때 크롤러가 한 번에 요청할 수 있는 문서 수를 지정할 수 있습니다. 또한 이 URL을 크롤링할 때 Office SharePoint Services 검색 서비스에서 한 번에 수행할 수 있는 최대 요청 수를 지정할 수 있습니다.
- 한 번에 문서 하나를 요청하고 요청 사이에 지정된 시간 동안 대기. 이 URL을 크롤링할 때 요청 사이의 지연 시간(초)을 지정할 수 있습니다. 이 옵션을 선택하면 Office SharePoint Server 검색 서비스에서 한 번에 사이트당 한 번만 요청하고 다음 요청까지 지정된 시간 동안 대기합니다. 대기 시간(초) 상자에 요청 사이에 대기할 시간을 초 단위로 입력합니다. 요청 사이에 대기하는 최소 시간은 1초이며 최대 시간은 1,000초입니다.
확인을 클릭합니다.

크롤러 영향 규칙에 대한 자세한 내용은 다음 문서를 참조하십시오.

크롤러 영향 관리(Office SharePoint Server 2007)
검색 환경의 성능 및 용량 요구 사항 예측의 "크롤러 영향 규칙"

WAN 가속기 및 기타 타사 도구

이 섹션에서는 다음과 같은 범주의 타사 솔루션으로 WAN 환경을 최적화하는 옵션에 대해 설명합니다.

WAN 가속기
오프로드 및 캐시 장치
클라이언트 솔루션
데이터 복제, 멀티 마스터 동기화 및 구성 관리
복수 팜 관리 및 보고
바이트 수준 또는 하드웨어 기반 복제

각 환경이 서로 다르므로 여기에서는 특정 파트너 솔루션을 권장하지 않습니다. 더구나 파트너 솔루션은 서로 다른 방식으로 기회를 처리합니다. 따라서 솔루션마다 장점이 다릅니다. 사용자 환경의 특정 요구 사항과 파트너 솔루션의 상대적인 장점을 바탕으로 각 솔루션을 평가해야 합니다.

Office SharePoint Server 2007 솔루션을 향상시키거나 최적화하는 솔루션을 제공하는 많은 파트너가 있습니다. 업데이트된 파트너 목록은 Microsoft Office System 솔루션 목록 (영문)(https://go.microsoft.com/fwlink/?linkid=108591&clcid=0x412)을 참조하십시오.

WAN 가속기

WAN 가속 솔루션은 오랫동안 사용되어 왔으며 최단 경로 알고리즘과 패킷 압축 도구가 수십 년 동안 제공되고 있습니다. 최근 몇 년 간의 가장 혁신적인 솔루션은 TCP/IP 스택과 SMB(서버 메시지 블록)의 최적화를 목표로 합니다.

대부분의 WAN 가속기는 쌍으로 작동하는데 한 장치가 SharePoint 제품 및 기술을 실행하는 서버 옆의 데이터 센터에 설치되고 다른 장치는 지점에 설치됩니다. 두 장치는 캐싱, 압축, 차이점 보관 및 두 장치 간에 전송되는 패킷을 최적화하는 독점적인 방법을 사용하여 WAN 트래픽을 최적화합니다. 두 장치가 인라인 장치이든, 캐시용 업그레이드가 포함된 단순한 네트워크 장비이든 간에 최적화 방법은 유사합니다. 파트너 솔루션에 따라 네트워크 스택에서 중점적으로 최적화하는 계층이 다릅니다.

네트워크 가속기를 선택할 때 고려할 두 가지 중요한 기준은 다음과 같습니다.

조직의 보안 요구 사항. IPsec 또는 HTTPS 등의 요구 사항이 선택에 영향을 미칩니다.
조직에서 사용되는 응용 프로그램. Microsoft Exchange Server와 파일 공유 트래픽에 대한 최적화도 제공하는 장치를 원하는 경우 이 기준도 선택에 영향을 미칩니다.

솔루션의 예로는 Cisco, Citrix, Packeteer, Riverbed, F5 등이 있습니다.

오프로드 및 캐시 장치

SharePoint의 캐싱 기술로 불필요한 백 엔드 트래픽을 줄일 수 있지만 오프로드 및 캐시 장치를 제공하는 파트너가 WAN 연결을 비롯한 클라이언트와 서버 간의 간격을 연결하는 데 도움이 될 수 있습니다.

인터넷을 통해 SharePoint 사이트를 호스팅하는 경우 네트워크 트래픽을 최적화하고 서버를 대상으로 하는 요청 수를 줄이는 것이 목표이면 오프로드 및 캐시 장치가 유용할 수 있습니다. 인터넷에 노출된 콘텐츠를 호스팅하는 프로세스를 최적화하기 위한 솔루션을 담당하는 다양한 파트너가 있습니다. 이 영역에서 채택되는 전략에는 캐싱 및 관련된 독점적 기술, 다양한 알고리즘을 사용하는 오프로드된 압축, 웜업 및 프리페치, 다양한 쇼핑 카트 기술 등이 포함됩니다. 일부 파트너는 공개 키오스크, 전 세계 인터넷 카페의 컴퓨터 또는 잘 연결되지 않는 간단한 장치와 같은 특정 유형의 클라이언트에 안전하고 효율적으로 콘텐츠를 제공하는 데 뛰어납니다.

또한 인터넷 분야에는 삭제되는 패킷을 줄이기 위한 전역 캐싱 및 네트워크 최적화 라우팅 기술을 제공하는 파트너도 있습니다. 예를 들어 일부 솔루션은 클라이언트 요청에서 변경된 부분만 서버에 전송되도록 네트워크 트래픽을 최적화합니다. 이러한 유형의 솔루션을 사용하면 WAN 트래픽이 줄어들며 페이지 반환이 더 빨라지므로 클라이언트와 서버 간이나 다른 중간 장치 간의 왕복 통신 수가 줄어들 수 있습니다.

Microsoft ISA와 마찬가지로 일부 솔루션은 오프로드되거나 위임된 인증을 정보에 액세스하기 위한 수단으로 제공합니다. 이러한 솔루션은 추가 보안 계층을 추가합니다. 여러 요구 사항을 처리하려면 방화벽 및 부하 분산과 오프로드 및 캐싱에 대한 지능을 제공하는 제품이나 솔루션을 찾으십시오. 이후에는 이러한 유형의 기능이 훨씬 더 통합될 것입니다.

솔루션의 예로는 Cisco, F5, Inktomi, Microsoft ISA Server, Microsoft Internet Application Gateway 등이 있습니다.

클라이언트 솔루션

일부 파트너는 네트워크 및 서버 인프라를 처리하는 대신 클라이언트 환경의 최적화를 중점적으로 다룹니다. 프리페치, 백그라운드 동기화, 압축, 광고 차단 및 이미지 필터와 같은 기술은 인터넷에서 콘텐츠를 검색하는 성능을 크게 높일 수 있습니다. 이는 텍스트가 주요 대상이고 이미지 없이 관리할 수 있는 경우에 특히 해당하는 사실입니다.

사용자가 SharePoint 사이트와 자동으로 동기화할 수 있도록 하는 몇 가지 클라이언트 응용 프로그램이 있습니다. 클라이언트가 사이트와 처음에 동기화한 후 클라이언트 응용 프로그램은 백그라운드에서나 클라이언트가 온라인일 때 클라이언트 컴퓨터의 사이트 콘텐츠를 자동으로 캐시합니다. 예를 들어 사용자가 문서를 클릭하면 문서가 이미 로컬에서 사용 가능하며 사용자가 WAN 링크의 영향을 받지 않습니다. 이와 마찬가지로 사용자가 문서를 추가하거나 업데이트할 때 클라이언트 응용 프로그램은 온라인 사이트와 변경 사항을 동기화하는 작업을 담당합니다. 일반적으로 이러한 클라이언트 응용 프로그램은 발생하는 충돌을 관리하며 사용자가 충돌을 해결하는 방법을 결정할 수 있도록 합니다.

일부 클라이언트는 다른 클라이언트보다 이 환경을 효과적으로 처리합니다. 응용 프로그램에 따라 파일에 대한 지원 기능만 제공하는 것도 있고 목록과 파일에 대한 지원 기능을 모두 제공하는 것도 있습니다. 오프라인 Wiki를 찾지 못할 수 있지만 대부분의 목록을 로컬로나 오프라인으로 사용하기 위한 RSS 수집기를 찾을 수 있습니다. Office Outlook 2007은 문서 라이브러리와 동기화하는 것 외에도 RSS 수집기와 함께 RSS를 사용하여 SharePoint 블로그나 목록을 오프라인으로 사용할 수 있도록 하는 클라이언트의 예입니다. Office Groove 2007에서는 훌륭한 오프라인 환경도 제공하며 WAN을 통한 피어-투-피어 공동 작업 및 파일 압축 기능을 추가합니다. Microsoft 클라이언트 솔루션에 대한 자세한 내용은 Office Outlook 2007 및 Office Groove 소프트웨어로 Office SharePoint Server 글로벌 솔루션 확장을 참조하십시오.

이 분야의 파트너는 WAN 링크가 성능에 영향을 미치거나 클라이언트가 자주 오프라인 상태인 사용자 환경의 최적화를 전문적으로 다룹니다. 캐싱(로컬 복사본), 압축 및 백그라운드로의 동기화 이동은 서버와 함께 LAN에 있는 듯한 느낌을 줄 수 있습니다. 클라이언트 응용 프로그램을 사용자에게 제공하도록 선택하는 경우 사용자가 가능한 한 효과적으로 작업할 수 있도록 적절한 교육을 제공해야 합니다.

파트너: Colligo. Microsoft: Microsoft Office Outlook 2007, Office Groove 2007

데이터 복제, 멀티 마스터 동기화 및 구성 관리

두 사무실 간의 느린 WAN 링크 때문이든, 멀티 마스터 요구 사항이 있는 재해 복구 요구 사항 때문이든 간에 복제는 배포 계획에서 흔히 필요합니다. SQL Server 2005에서는 재해 복구나 사이트 장애 조치(failover)를 위한 로그 전달과 데이터베이스 미러링을 제공합니다. 그러나 읽기/쓰기 권한을 제공하는 별도의 두 서버 팜이 필요한 경우 솔루션을 제공하는 파트너가 있습니다.

일부 파트너 솔루션에는 WAN 가속기와 유사한 서버 캐시가 포함됩니다. 이러한 솔루션은 WAN 링크가 작동하지 않는 경우 원격 사이트의 캐시에서 콘텐츠를 계속 제공합니다. 다른 파트너는 오랫동안 연결이 끊어진 후에 사이트가 연결되는 경우 데이터를 동기화하는 데 뛰어납니다. 예를 들어 오랜 항해 후에 항구에 도착하는 선박은 중앙 사이트와 동기화할 수 있습니다.

일부 파트너는 웹 응용 프로그램, 사이트 모음 또는 목록의 쌍에 대한 복제를 구성하도록 SharePoint 제품 및 기술 인터페이스를 확장합니다.

참고

제품 팀은 WAN 환경에서 Office SharePoint Server 2007의 게시 기능을 아직 테스트하지 않았습니다. 게시 기능은 중앙 팜에서 읽기 전용 환경으로 콘텐츠를 게시할 때 특정 값을 제공할 수도 있습니다. 그러나 테스트 결과가 없으므로 이 시나리오에 대한 특정 지침을 제공할 수 없습니다.

파트너 솔루션: Syntergy, WinApp Technologies, Casahl 및 Infonic

복수 팜 관리 및 보고

여러 서버 팜이 포함된 전역 배포에서는 여러 팜과 사이트에서 설정을 관리하기가 어려울 수 있습니다. 몇몇 파트너가 구성 설정, 사용 권한 관리, 효과적인 사용자 권한, 마스터 페이지 및 콘텐츠 형식과 같은 콘텐츠 요소 등의 관리를 간소화하기 위해 디자인된 도구를 제공합니다. 사용자 환경에 여러 서버 팜을 배포하도록 결정한 경우 여러 팜과 대규모 사이트를 관리하는 데 유용할 수 있는 파트너 도구를 고려하십시오.

일부 파트너는 여러 팜과 여러 환경에서 설정을 구성하는 작업을 전문적으로 지원합니다. SharePoint 사이트 간 구성기 (영문)(https://go.microsoft.com/fwlink/?linkid=108592&clcid=0x412)는 웹 응용 프로그램 간의 일관성을 위해 감사, 만료, 마스터 페이지 및 콘텐츠 형식을 구성할 수 있도록 Microsoft에서 디자인한 도구의 예입니다.

파트너 솔루션: Quest Software, echoTechnologies, IDevFactory, AvePoint , CorasWorks, Barracuda Tools, CommVault 및 Symantec

바이트 수준 또는 하드웨어 기반 복제

하드웨어 기반 또는 바이트 수준 복제를 제공하는 파트너는 데이터 센터 간에 환경을 장애 조치하고 동기화하는 작업을 매우 쉽게 수행할 수 있도록 합니다. SAN(저장 영역 네트워크)과 같은 공유 디스크를 구현하는 경우 공유 디스크가 실패 지점이 될 수 있습니다. 하드웨어 공급업체는 중복 채널, 중복 파이버, 중복 디스크 및 다양한 배열 구성을 제공하기 위해 다양한 방법을 사용합니다. 솔루션마다 다른 수준의 내결함성을 제공합니다.

가능한 실패 원인에서 하드웨어를 제거하려면 Microsoft Cluster Services(MSCS)를 고려하십시오. MSCS는 하드웨어 기반 내결함성을 제공합니다. SQL 로그 전달 및 SQL 미러링과 같은 소프트웨어 기반 장애 조치 솔루션은 하드웨어 내결함성을 제공하지만 장애 조치는 SharePoint 제품 및 기술과 함께 사용될 때 자동으로 수행되지 않습니다.

경우에 따라 스택의 낮은 수준에서 복제를 제공하는 솔루션을 구현하여 특정 비즈니스 요구를 처리할 수 있습니다. 기본 환경의 복제나 미러를 만드는 바이트 수준 복제는 장애 조치할 보조 환경도 만들 수 있습니다. 지속적인 바이트 수준 복제는 자동 또는 수동 장애 조치 수단을 제공할 수 있습니다.

이러한 유형의 복제 솔루션을 평가할 때는 서버 이름, 웹 응용 프로그램 이름 및 계정이 구성 데이터베이스에서 하드 코딩되는 것을 이해해야 합니다. 즉, 다른 이름으로 다른 서버에 복제되는 서비스는 작동하지 않습니다. 서버 이름이 복제된 환경에서 기본 환경과 동일하게 유지되는 경우 이러한 유형의 솔루션이 작동할 수 있습니다. 솔루션에 관계없이 도구가 응용 프로그램에서 인식할 수 없는 복제를 제공하는 경우 도구를 테스트하여 장애 조치 환경에서 작동하는지 확인해야 합니다.

파트너 솔루션: Neverfail 및 Double-take

SAN 기반 복제와 같은 하드웨어에 빌드된 솔루션: HP, EMC Centera 및 Hitachi Data Systems

더욱 빠른 다운로드를 위한 페이지 디자인

네트워크 용량이 제한된 환경에서는 페이지를 간소화하고 가능한 한 작고 응답 속도가 빠르게 만듭니다. 이렇게 하는 기술은 여러 가지이며 대부분 SharePoint 제품 및 기술에만 한정되지 않습니다. 모든 웹 사이트에서 사용할 수 있는 일반적인 방법은 이 섹션에서 자세하게 설명하지 않습니다. 대신 이 섹션에서는 SharePoint 제품 및 기술에 포함된 기능, 페이지에 포함된 항목, SharePoint 사이트에 처음 방문하는 속도를 높일 수 있는 방법을 중점적으로 살펴봅니다.

페이지 요소

SharePoint 사이트의 페이지는 다음 그림과 같이 몇 가지 고유한 요소로 구성되어 있습니다.

컨트롤 오버레이가 포함된 SharePoint 사이트 페이지

페이지가 렌더링될 때 마스터 페이지, 레이아웃 페이지 및 페이지 콘텐츠가 함께 제공됩니다. 페이지 콘텐츠에는 각 페이지 필드에 대한 값뿐만 아니라 테마, 스타일시트, 이미지, 탐색 등의 다양한 요소도 포함됩니다. 다음 표에서는 SharePoint 사이트의 단일 페이지에 있는 파일과 스트림의 예를 보여 줍니다. 이 예는 공동 작업 포털 사이트의 기본 홈 페이지에 처음 방문할 때 수행된 모든 HTTP 요청을 캡처한 것입니다.

URL	크기(바이트)
http://myServer/_layouts/images/topnavhover.gif	96
http://myServer/Pages/Default.aspx	1656
http://myServer/Pages/Default.aspx	1539
http://myServer/Pages/Default.aspx	66084
http://myServer/_layouts/1033/styles/controls.css?rev=EhwiQKSLiI%2F4dGDs6DyUdQ%3D%3D	1448
http://myServer/_layouts/1033/styles/HtmlEditorCustomStyles.css?rev=8SKxtNx33FmoDhbbfB27UA%3D%3D	642
http://myServer/_layouts/1033/styles/HtmlEditorTableFormats.css?rev=guYGdUBUxQit03E2jhSdvA%3D%3D	1317
http://myServer/_layouts/1033/styles/core.css?rev=5msmprmeONfN6lJ3wtbAlA%3D%3D	13596
http://myServer/_layouts/1033/init.js?rev=VhAxGc3rkK79RM90tibDzw%3D%3D	15732
http://myServer/_layouts/1033/core.js?rev=F8pbQQxa4zefcW%2BW9E5g8w%3D%3D	54367
http://myServer/_layouts/portal.js?rev=INhSs9mWTnUTqdwwIXYMaQ%3D%3D	954
http://myServer/_layouts/1033/ie55up.js?rev=Ni7%2Fj2ZV%2FzCvd09XYSSWvA%3D%3D	20508
http://myServer/_layouts/1033/search.js?rev=yqBjpvg%2Foi3KG5XVf%2FStmA%3D%3D	5092
http://myServer/_layouts/1033/EditingMenu.js?rev=eh0f0CwzvHQ7Ii0JvdsIjQ%3D%3D	2735
http://myServer/WebResource.axd?d=__WrA1TRLicJgwGEmYKqSA2&t=633214754549731034	5383
http://myServer/WebResource.axd?d=h_u9v0Coj_eDqsvEkDrdtw2&t=633214754549731034	8258
http://myServer/_layouts/images/blank.gif	43
http://myServer/_layouts/images/helpicon.gif	1025
http://myServer/_layouts/images/Menu1.gif	68
http://myServer/_layouts/images/titlegraphic.gif	1299
http://myServer/_layouts/images/gosearch.gif	19933
http://myServer/WebResource.axd?d=puevA5kEAx44yxozBd-hspPZ9eA51Rh9u95VwVGLFCc1&t=633214754549731034	224
http://myServer/WebResource.axd?d=wyTuS1folQ6wX2Tc_7NOOaeElHHqL6rtdeAeRRUR36s1&t=633214754549731034	218
http://myServer/_layouts/images/whitearrow.gif	68
http://myServer/_layouts/images/recycbin.gif	1004
http://myServer/PublishingImages/newsarticleimage.jpg	10710
http://myServer/_layouts/images/icongo01.gif	1171
http://myServer/_layouts/images/menudark.gif	68
http://myServer/_layouts/images/topnavhover.gif	96

다음과 같은 사항을 확인할 수 있습니다.

페이지를 다운로드하는 데 필요한 요청은 총 29개입니다.
총 페이지 크기는 235KB입니다.
이것은 초기 페이지 로드를 나타냅니다. 요청의 거의 모든 항목에는 1년 동안 해당 항목을 다시 로드하지 않도록 브라우저에 지시하는 캐싱 지시문이 있습니다. 두 번째와 이후의 페이지 로드에서는 요청이 3개만 생성됩니다. 이 중에서 2개는 발생하는 NTLM 협상의 일부이므로 한 항목(페이지의 HTML)만 실제로 다운로드됩니다.
가능한 최소한의 압축량인 기본 IIS 압축 수준 0이 사용되었습니다. 추가로 압축하면 다운로드 크기가 훨씬 작아집니다.
로드되는 파일 형식에는 다음이 포함됩니다.
- 4개의 .axd 리소스 요청
- 4개의 .css 리소스 요청
- 12개의 이미지 리소스 요청
- 6개의 .js 리소스 요청(이 중 몇 개는 중복됨)
- default.aspx에 대한 3개의 페이지 리소스 요청(이 중 2개는 NTLM 협상의 일부임)

이러한 파일 형식은 대부분 상당히 명확하지만 .axd 리소스 종류는 예외일 수 있습니다. .axd 리소스는 ASP.NET 버전 2.0에 포함된 새로운 기능의 일부입니다. 개발자는 스크립트 파일이나 스타일시트와 같은 리소스를 컨트롤에 추가할 수 있습니다. 개발자는 컨트롤에서 ClientScript 클래스를 사용하여 GetWebResourceUrl이라는 메서드를 포함할 수 있습니다. 컨트롤은 런타임에 렌더링될 때 리소스의 URL을 동적으로 생성합니다. 리소스 자체가 컨트롤 어셈블리로 컴파일되므로 이 방법을 사용하여 웹 서버에 있는 별도의 파일인 것처럼 해당 리소스를 어셈블리에서 클라이언트로 스트리밍할 수 있습니다.

페이지에서 사용되는 리소스 요청을 알고 있으면 최적화가 적용될 수 있는 위치와 방법을 이해하는 데 도움이 될 수 있습니다. 다양한 도구와 기술을 사용하여 이러한 종류의 정보를 측정할 수 있습니다. 이 문서에서는 Fiddler (영문)라는 프리웨어 도구가 사용되었습니다. Fiddler는 클라이언트 워크스테이션에서 실행될 수 있으며 페이지에 대해 수행된 모든 HTTP 요청을 추적하고 다음 그림과 같이 결과를 표로 표시합니다.

SharePoint 사이트에 대한 Fiddler 결과

사이트를 최적화하기 위해 변경하는 경우 Fiddler를 사용하여 사이트를 테스트하십시오. 요청되는 항목, 캐시되는 항목 및 각 항목의 크기를 정확히 파악하려면 다음 단계를 수행합니다.

브라우저의 임시 파일을 모두 삭제합니다.
Fiddler를 시작합니다.
페이지를 요청합니다.

참고

링크를 클릭하여 페이지를 요청해야 합니다. 새로 고침 단추를 클릭하면 항목이 자동으로 다시 요청되고 수행된 최적화 변경 사항이 정확하게 반영되지 않습니다.

페이지 다운로드 최적화

페이지의 구성을 이해한 후 여러 가지 방법을 사용하여 해당 페이지에 대한 다운로드 환경을 최적화할 수 있습니다. 일반적으로 목표는 클라이언트 컴퓨터와 서버 컴퓨터 간의 왕복 수를 최소화하고 네트워크를 통해 전송되는 데이터의 양을 줄이는 것입니다. 이 문서의 지침에는 SharePoint 제품 및 기술의 다양한 구현에 광범위하게 적용될 수 있는 권장 사항이 포함되어 있습니다.

이러한 권장 사항을 검토할 때와 개발할 수 있는 다른 모든 사용자 지정 최적화를 검토할 때 명심해야 할 중요한 구분이 있습니다. 페이지 최적화 기술은 첫 번째 페이지 요청과 이후 페이지 요청이라는 두 범주 중 하나로 나뉩니다. 첫 번째 페이지 요청에 대한 최적화는 페이지가 처음 요청될 때 구현되지만 이후 페이지 요청에 반드시 영향을 미치지는 않는 유형의 최적화입니다. 이후 페이지 요청에 대한 최적화는 사용자가 페이지를 처음 요청하든 50번째로 요청하든 간에 사용자 환경을 개선할 수 있는 유형의 최적화입니다. 핵심적인 사항은 기능의 손실과 얻은 이점 사이의 균형을 유지하는 것입니다. 사용자가 사이트를 처음 방문할 때만 이점이 실현되는 경우에는 기능의 손실을 감수하고 최적화를 적용하는 것이 적당하지 않을 수 있습니다.

BLOB 캐시

BLOB(Binary Large Object) 캐시는 이 문서의 뒷부분에서 자세히 설명합니다. 간략하게 설명하면, BLOB를 사용하여 캐싱 지시문을 SharePoint 제품 및 기술에 저장된 페이지의 항목에 적용할 수 있습니다. 이러한 캐싱 지시문이 포함된 경우 캐시된 항목이 만료될 때까지 브라우저가 해당 항목을 다시 다운로드하려고 하지 않습니다. 이전 홈 페이지 예제에서 알 수 있듯이 공동 작업 포털 사이트 서식 파일에 대한 기본 홈 페이지에 포함된 거의 모든 항목에는 항목과 관련된 캐싱 지시문이 있습니다. 이 때문에 이러한 항목이 이후 페이지 방문 시 요청되지 않습니다. BLOB 캐시를 설정하고 구성하는 방법에 대한 자세한 내용은 이 문서 뒷부분의 WAN 환경에 맞게 캐싱 최적화를 참조하십시오.

IIS 압축

IIS 압축도 이 문서의 WAN 환경에 맞게 캐싱 최적화 섹션에서 자세히 설명합니다. 그러나 이전에 언급했듯이 기본 설정은 압축 수준 0을 사용하는 것입니다. 웹 서버의 CPU에 대한 영향을 최소화하면서 압축을 최적화하는 수준을 찾을 때까지 다양한 압축 설정 수준을 테스트해야 합니다. 거의 모든 경우에 0보다 큰 압축 수준을 사용할 수 있습니다. 그러나 압축 수준은 .axd 및 .aspx 파일과 같은 동적 파일에만 적용되는 것을 명심해야 합니다.

64비트 하드웨어

팜에서 선택된 하드웨어는 요청 대기 시간에도 영향을 미칠 수 있습니다. 32비트 시스템의 메모리 제한은 응용 프로그램당 2GB의 RAM입니다. 응용 프로그램 지원을 3GB의 RAM으로 확장할 수 있지만 SharePoint 제품 및 기술은 /3GB 스위치의 사용을 지원하지 않습니다. 메모리가 부족한 상황은 다음과 같은 방식으로 요청 대기 시간에 부정적인 영향을 미칠 수 있습니다.

메모리 양이 제한되면 SharePoint 응용 프로그램 풀이 재활용될 수 있습니다. 이렇게 되면 ASP.NET 응용 프로그램 도메인도 재활용되므로 사용자 요청에 응답하는 데 시간이 오래 지연될 수 있습니다.
메모리 부족 오류로 인해 BLOB 캐시의 콘텐츠 처리가 중지될 수 있습니다.

64비트 하드웨어를 사용하면 충분한 RAM을 할당하고 사용하여 이러한 오류를 방지할 수 있습니다.

웹 가든 설정

웹 가든 설정으로 인해 BLOB 캐시가 일관성 없게 작동할 수도 있습니다. 한 프로세스만 캐시 관리에 필요한 잠금을 얻을 수 있기 때문에 캐시의 성공적인 사용 여부는 요청을 처리하는 스레드에 따라 달라집니다. BLOB 캐시 잠금이 없는 웹 가든이 요청을 처리하는 경우 웹 가든이 응답으로 보내는 콘텐츠에는 캐싱 지시문이 연결되어 있지 않습니다. 이 경우 요청 수와 네트워크를 통해 전송되는 데이터의 양이 모두 증가합니다. 따라서 BLOB 캐시를 사용하려는 경우에는 웹 가든을 사용하면 안 됩니다.

페이지에서 보호된 항목 최소화

사용자가 SharePoint 제품 및 기술에 인증할 때 두 가지 사항이 발생합니다. 첫째, 시스템에서 자격 증명의 유효성을 검사하여 사용자가 누구인지 확인합니다. 둘째, 역할 공급자가 사용자가 속한 SharePoint 그룹의 목록을 열거합니다. 페이지가 요청될 때마다 역할 공급자가 다시 호출되어 사용자가 속한 모든 그룹을 열거합니다.

그러나 그룹 등록에 대한 이 호출은 한 페이지에서 여러 번 발생할 수 있습니다. 예를 들어 기본 공동 작업 포털 사이트 서식 파일 페이지에서는 사용자가 홈 페이지로 이동할 때 역할 공급자를 두 번 호출해야 합니다. 여기에서 한 번은 페이지 자체를 위한 호출이고 다른 한 번은 페이지의 이미지를 위한 호출입니다. SharePoint 라이브러리에 저장되고 페이지에 있는 각 이미지는 모든 이미지가 동일한 이미지 라이브러리에 저장된 경우에도 역할 공급자에 대한 추가 호출을 통해 사용 권한을 확인합니다. 이 확인은 이미지가 페이지에서 필드로 추가되었든(즉, 페이지 콘텐츠의 일부임), 사이트의 마스터 페이지에 추가되었든 간에 발생합니다.

제한된 대역폭이나 대기 시간이 긴 환경을 위해 개발된 사이트는 페이지에서 사용되는 이미지 수를 최소화하도록 디자인되어야 합니다. 많은 사이트에서 마스터 페이지의 일부로 몇 가지 이미지를 사용하여 다양한 시각 효과를 생성합니다. 보안 검사 수가 늘어나면 대기 시간이 증가하므로 이미지를 가능한 한 적게 사용하여 이러한 환경을 위한 사이트를 디자인하십시오.

이미지 수 및 크기 최소화

이전 섹션에서 설명했듯이 사이트에서 이미지 수를 최소화해야 합니다. 이를 위해 한 파일에 여러 이미지를 포함한 다음 페이지에서 개별 이미지를 참조할 수 있습니다. 파일 다운로드 크기가 줄어들 뿐만 아니라 파일 수가 적어지면 네트워크 트래픽도 줄어듭니다. 이 기술을 사용하여 페이지를 작성하는 것은 더 복잡하지만 모든 왕복과 파일 크기가 중요한 상황에서는 성능을 개선하는 데 중요한 방법일 수 있습니다. 다음 그림에서는 여러 이미지가 포함된 한 이미지 파일의 예를 보여 줍니다.

행 안의 6개 아이콘 이미지

다음 그림에서는 이 이미지가 이후에 변경되어 표에 개별 그림으로 표시되는 모양을 보여 줍니다.

표 안의 6개 아이콘 이미지

이미지 조작은 전적으로 스타일시트 클래스를 통해 수행되었습니다. 각 표 셀의 div 및 img 요소에서 두 가지 기본 클래스가 사용되었습니다. 이러한 클래스는 다음과 같습니다.

.cluster {

height:50px;

position:relative;

width:50px;

}

.cluster img {

position:absolute;

}

각 이미지에는 이미지의 ID(식별자)에 따라 클래스가 연결되어 있습니다. 해당 스타일은 그림을 잘라내고 클러스터의 초기 그림에서의 오프셋을 정의합니다. 이러한 클래스는 다음과 같습니다.

#person {

border:none;

clip:rect(0, 49, 49, 0);

}

#keys {

clip:rect(0, 99, 49, 50);

left:-50px;

}

#people {

clip: rect(0, 149, 49, 100);

left:-100px;

}

#lock {

clip:rect(0, 199, 49, 150);

left:-150px;

}

#phone {

clip:rect(0,249, 49, 200);

left:-200px;

}

#question {

clip:rect(0, 299, 49, 250);

left:-250px;

}

표의 HTML에는 다음과 같이 적절한 ID 값 및 클래스 이름이 포함된 div 및 img 태그가 들어 있습니다.

<table border="1">

<tr>

<td><div class="cluster"><img id="person" src="Icons50x50.gif" width="300" height="50"/></div></td>

<td><div class="cluster"><img id="keys" src="Icons50x50.gif" width="300" height="50"/></div></td>

<td><div class="cluster"><img id="people" src="Icons50x50.gif" width="300" height="50"/></div></td>

</tr>

<tr>

<td><div class="cluster"><img id="lock" src="Icons50x50.gif" width="300" height="50"/></div></td>

<td><div class="cluster"><img id="phone" src="Icons50x50.gif" width="300" height="50"/></div></td>

<td><div class="cluster"><img id="question" src="Icons50x50.gif" width="300" height="50"/></div></td>

</tr>

</table>

여러 Microsoft 웹 속성과 제품은 이제 Microsoft Passport Network 및 Microsoft Office Outlook Web Access(OWA)를 비롯하여 이 기술을 사용합니다. MSN 팀은 성능 테스트를 수행하여 변경의 영향을 분석하고 첫 페이지의 로드 시간이 50-75% 향상된 것을 확인했습니다.

Microsoft Office SharePoint Designer 2007에서 페이지를 작성하는 경우 고려할 중요한 점이 있습니다. Office SharePoint Designer 2007에서 새 페이지를 만들 때 다음과 같은 XHTML 스키마 태그가 페이지에 자동으로 추가됩니다.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

It then adds this namespace to the HTML element:

<html xmlns="http://www.w3.org/1999/xhtml">

이 스키마를 사용하는 경우 이미지가 제대로 정렬되지 않습니다. 이미지가 의도한 대로 나타나게 하려면 HTML 태그에서 xmlns 속성을 제거해야 합니다.

core.js 다운로드 지연

Office SharePoint Server 2007에 포함된 기본 클라이언트 스크립트 파일을 core.js라고 합니다. 이 파일은 압축되지 않은 경우 약 257KB이고 압축된 경우 약 54KB인 가장 큰 스크립트 파일입니다. 특정한 상황에서는 core.js의 다운로드를 지연할 수 있습니다. 이렇게 하면 페이지가 브라우저에서 열릴 때까지 core.js 파일의 다운로드가 시작되지 않기 때문에 페이지가 더 빠르게 렌더링되며, 이에 따라 사용자가 더 빨리 페이지를 보고 콘텐츠를 읽기 시작할 수 있습니다. 이 기술은 익명 사용자가 있는 인터넷 시나리오에서 가장 유용합니다. 반대로, 인증된 사용자의 경우에는 사이트 작업 메뉴와 같은 기능이나 UI 요소를 사용하기 위해 페이지 로드 시에 core.js가 다운로드되어야 합니다.

다음 단계를 사용하여 이 기술을 구현할 수 있습니다.

core.js를 사용하지 않는 사용자 지정 레이아웃 페이지를 만듭니다. 이 레이아웃 페이지는 홈 페이지와 함께 사용되므로 사이트의 초기 방문자가 core.js가 즉시 다운로드될 때까지 기다릴 필요가 없습니다. 새 레이아웃 페이지는 기존 홈 페이지와 호환되어야 하므로 레이아웃 페이지에서 현재 사용 중인 동일한 연결된 콘텐츠 형식을 포함해야 합니다.

참고

기본적으로 공동 작업 포털 사이트에서는 시작 페이지 콘텐츠 형식이 지정됩니다.
페이지에 <SharePointWebControls:ScriptLink runat="server"/> 태그를 추가합니다. 이 태그는 참조되지 않는 경우 core.js를 사용하지 않도록 시스템에 지시합니다.
인증된 사용자를 확인하기 위해 사용자 지정 컨트롤을 만듭니다. 이 컨트롤은 매우 간단하며 기본적으로 다음과 같은 코드를 포함합니다(C#으로 표시됨).
```
if (HttpContext.Current.Request.IsAuthenticated)   
    Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);
```
각 웹 서버에서 GAC(전역 어셈블리 캐시)에 컨트롤을 넣은 다음 컨트롤이 사용될 웹 응용 프로그램의 Web.config 파일에서 컨트롤에 대한 SafeControl 항목을 추가합니다.
1단계에서 만든 사용자 지정 레이아웃 페이지에 사용자 지정 컨트롤을 추가합니다.

레이아웃 페이지에 IFRAME을 추가합니다. IFRAME은 다음과 같은 콘텐츠가 있는 페이지를 참조해야 합니다.

<body>
<SharePoint:ScriptLink name="core.js" runat="server" />
<script language="javascript">
 DisableRefreshOnFocus();
</script>
</body>

사용자 지정 레이아웃 페이지를 체크 인하고 게시합니다.
새 레이아웃 페이지를 바탕으로 사이트의 홈 페이지를 만듭니다.

위의 단계를 수행한 후 사이트의 홈 페이지를 테스트하여 작동하는지 확인합니다. 처음 방문하는 익명 사용자는 페이지 원본에서 core.js에 대한 참조를 볼 수 없지만 core.js는 브라우저 캐시에 들어가게 됩니다.

또한 이 기술을 채택하기 전에 다음을 고려합니다.

사이트 마스터 페이지와 시스템 마스터 페이지가 달라야 합니다. 다르지 않으면 _layouts의 모든 페이지가 제대로 작동하지 않습니다.
로드 시 core.js가 작동해야 하는 컨트롤이 마스터 페이지에 포함되지 않게 합니다.
core.js를 로드하거나 참조하는 ScriptLink 컨트롤이 마스터 페이지에 포함되지 않게 합니다.

자세한 내용과 예제 코드를 보려면 Microsoft ECM(엔터프라이즈 콘텐츠 관리) 팀 블로그 (영문)(https://go.microsoft.com/fwlink/?linkid=106008&clcid=0x412)를 참조하십시오.

목록 보기 페이지 최적화

Microsoft 서비스 팀은 목록 보기 페이지 렌더링 시간의 성능을 측정하고 개선하기 위해 노력하고 있습니다. 목록 보기 페이지는 콘텐츠를 검색할 수 있도록 하기 위해 각 목록과 라이브러리에서 사용되는 AllItems.aspx 페이지입니다. 이 페이지의 렌더링 시간은 보기에서 표시되는 열의 수와 열의 형식에 따라 크게 달라질 수 있습니다. 예를 들어 표시 옵션과 현재 상태 아이콘은 렌더링 시간에 크게 영향을 미칠 수 있습니다. 축소된 그룹이 확장된 그룹보다 렌더링하는 데 시간이 훨씬 더 걸리며 둘 모두 그룹이 전혀 없는 경우보다 느립니다.

이러한 차이 때문에 특히 느린 네트워크 링크를 사용하는 경우 목록 보기 페이지에서 보기가 구성되는 방식을 신중하게 고려해야 합니다. 많은 데이터가 포함된 목록으로 작업할 때는 특히 기본 보기를 비롯한 모든 보기를 신중하게 조정해야 합니다. 일반적으로 다음과 같은 방법으로 목록 보기 페이지의 렌더링 시간을 단축할 수 있습니다.

더 적은 열 표시
현재 상태 정보가 포함된 열 제외
링크(편집 메뉴 없음)를 사용하여 항목 정보 보기

다음 표에서는 보기를 렌더링하는 데 필요한 시간을 줄이는 사용자 지정에 대해 설명합니다.

항목	설명
보기 형식	표준 보기 대신 데이터시트 보기로 보기를 만듭니다.
보기: 항목 제한	1,000개가 넘으면 느리게 렌더링되기 쉽습니다. 느린 연결에서는 테스트를 통해 한 번에 표시되는 데이터 양과 모든 데이터를 표시하는 데 필요한 왕복 수 간의 적당한 균형을 찾아야 합니다. 한 번에 표시되는 행 수가 많아질수록 왕복 수가 줄어들지만 페이지 크기가 커집니다.
보기: 필터	최신성이나 할당별로 항목을 필터링하려면 [오늘] 및 [나]를 사용합니다. 기본 보기에서 활성 항목만 표시하려면 상태 필드를 사용합니다.
보기: 열	필요한 최소한의 열만 사용합니다. 이후에 사용자가 드릴다운할 수 있는 높은 수준의 검색을 허용하는 몇 개의 열로 기본 보기를 만듭니다.

다음 표에서는 보기를 렌더링하는 데 필요한 시간을 늘리는 사용자 지정에 대해 설명합니다. 추가되는 각 열은 1,000개 항목으로 구성된 목록의 경우 빠른 네트워크 연결을 통해 열당 0.5초까지 렌더링 시간을 증가시킵니다. 표에 나와 있듯이 일부 열은 렌더링 시간을 더 증가시킵니다.

항목	설명
그룹화	그룹으로 묶으면 HTML 및 JScript가 추가되므로 큰 목록의 렌더링 속도가 느려집니다. 모든 그룹이 기본적으로 축소되게 설정하면 브라우저 개체 모델에서의 추가 작업 때문에 실제로 렌더링 시간이 더 늘어납니다.
열 – 편집 메뉴가 있는 항목에 연결된 제목	"편집 메뉴가 있는 항목에 연결됨" 옵션은 시간이 가장 오래 걸립니다. 유사한 옵션인 "항목에 연결됨"은 렌더링 시간을 눈에 띄게 증가시키지 않습니다.
열 – 현재 상태를 사용한 사용자 조회	현재 상태가 있는 사용자 조회 필드를 추가하면 현재 상태 메뉴를 여는 각 링크의 HTML이 추가됩니다. 또한 현재 상태를 사용할 수 있는지 확인하기 위해서도 대역폭이 사용됩니다.

다음 표에서는 보기를 렌더링하는 데 필요한 시간에 비교적 적은 영향을 미치는 사용자 지정에 대해 설명합니다.

항목	설명
정렬, 합계	여러 정렬과 합계를 적용하면 눈에 띄게 렌더링 시간이 증가하지만 일반적으로 각 정렬과 합계는 1,000개의 항목으로 구성된 목록의 경우 1초 미만이 걸립니다.

WAN 환경에 맞게 캐싱 최적화

Office SharePoint Server 2007에는 다양한 캐싱 옵션이 있습니다. 이러한 옵션은 서버에서 요청을 받은 때부터 응답이 클라이언트 컴퓨터에 스트리밍되기 시작할 때까지의 렌더링 파이프라인 전반에서 향상을 목표로 합니다. 캐싱은 전체적인 사이트 성능의 중요한 측면이지만 이 섹션에서는 다음과 관련하여 캐싱을 집중적으로 살펴봅니다.

클라이언트 캐싱에 대한 서버 구성의 역할
서버에서 클라이언트로 네트워크를 통해 전송되는 항목의 크기 제어

BLOB 캐시

BLOB 캐시는 Office SharePoint Server 2007 게시 기능에서만 사용할 수 있는 메커니즘입니다. 이에 따라 BLOB 캐시는 공동 작업 포털 사이트 서식 파일 기반의 회사 포털 사이트와 게시 포털 사이트 서식 파일 기반의 인터넷 소개 사이트에 사용하는 데 이상적입니다. BLOB 캐시를 사용하여 페이지 라이브러리 및 사이트 모음 이미지와 같은 게시 사이트 목록에서 처리되는 항목과 연결되는 캐싱 지시문을 구성할 수 있습니다. 클라이언트 컴퓨터의 브라우저는 캐싱 지시문을 발견하는 경우 검색하고 있는 항목을 로컬로 저장할 수 있으며 캐싱 지시문이 만료될 때까지 다시 요청할 필요가 없음을 감지합니다. 이에 따라 요청되고 네트워크를 통해 전송되는 항목의 수가 줄어들기 때문에 BLOB 캐시는 지리적으로 분산된 환경에서 상당히 중요합니다.

Office SharePoint Server 2007에서 BLOB 캐시가 설정되면 몇 가지 작업이 수행됩니다. 먼저, 캐시 가능한 항목이 요청될 때마다 Office SharePoint Server 2007에서는 요청을 받은 웹 서버의 하드 디스크 드라이브를 검색하여 복사본이 로컬 디스크에 있는지 확인합니다. 복사본이 로컬 디스크에 있으면 파일이 로컬 디스크에서 직접 사용자에게 스트리밍됩니다. 복사본이 로컬 디스크에 없으면 항목이 저장된 SQL 데이터베이스에서 항목의 복사본이 만들어진 다음 요청한 사용자에게 전송됩니다. 이 시점부터 항목에 대한 모든 요청은 항목의 캐시 가능성 값이 만료를 나타낼 때까지 웹 서버에서 직접 처리될 수 있습니다. 이에 따라 데이터베이스 서버에서 경합이 줄어들므로 서버 팜에서 성능이 향상됩니다.

또한 항목이 클라이언트에 전송될 때 항목에 캐시 가능성 헤더가 추가됩니다. 이 헤더는 항목이 캐시될 기간을 브라우저에 지시합니다. 예를 들어 그림의 캐시 가능성 값이 3일인 경우 브라우저는 그림이 3일 안에 다시 요청되면 로컬 캐시에 있는 이미지의 복사본을 사용하고 서버에서 이미지를 다시 요청하지 않습니다.

사이트를 테스트하여 캐시되는 항목과 항목이 캐시되는 방법을 확인하는 경우 Fiddler (영문)(http://www.fiddler2.com/fiddler2/)를 사용할 수 있습니다. 다음 스크린샷은 게시에 사용되는 간단한 SharePoint 사이트에 대한 Fiddler 캡처입니다. 사이트는 기본 공동 작업 포털 사이트 서식 파일을 사용하여 만들어졌습니다. 추가 텍스트 콘텐츠가 페이지에 추가되었고 몇 가지 이미지가 마스터 페이지에 추가되었습니다.

Fiddler 도구 결과

Fiddler 응용 프로그램에는 몇 가지 중요한 정보가 포함되어 있습니다.

왼쪽의 # 열은 페이지를 렌더링하기 위해 브라우저에서 서버로 총 44개의 HTTP 요청이 수행되었음을 나타냅니다.
Result 열에는 항목에 대한 요청에서 반환된 HTTP 결과 코드가 표시됩니다. 200 결과는 항목이 성공적으로 검색되었음을 의미합니다.
URL 열은 요청되는 특정 항목을 나타냅니다.
Body 열은 각 항목의 크기를 나타냅니다.
Caching 열에는 각 항목과 연결된 캐싱 지시문이 표시됩니다. Caching 열의 데이터는 몇몇 항목에 캐싱 지시문이 연결되어 있음을 나타냅니다. 즉, 이러한 항목에는 0보다 큰 MaxAge 특성이 있습니다. 캐싱 지시문은 초 단위로 표현됩니다. 위에 표시된 예제 페이지의 경우 몇몇 항목이 365일(1분이 60초이고, 1시간이 60분이고, 하루가 24시간이므로 60x60x24 = 86,400x365 = 31,536,000) 동안 캐시되도록 구성됩니다.

캐싱 지시문이 있는 항목은 모두 _layouts 디렉터리에 있습니다. 그 이유는 _layouts/images 가상 디렉터리가 IIS에서 구성되는 방식 때문입니다. 새로운 웹 응용 프로그램을 만드는 경우 Office SharePoint Server 2007에서는 웹 서버의 실제 디스크에 있는 폴더에 매핑되는 몇 가지 가상 디렉터리를 자동으로 만듭니다. 또한 _layouts/images 가상 디렉터리를 만들 때 전체 디렉터리에 적용되는 캐싱 지시문을 추가합니다. 다음 스크린샷에서는 IIS 관리자 스냅인에서 디렉터리에 대한 구성을 보여 줍니다.

이미지 폴더에 대한 IIS 관리자 속성

이러한 항목에 모두 0이 아닌 캐싱 지시문이 연결되어 있기 때문에 다음에 페이지가 요청될 때 브라우저는 서버에서 항목을 다시 요청하는 대신 로컬 브라우저 캐시에서 항목의 복사본을 사용합니다. 다음 스크린샷에서는 페이지가 두 번째로 요청된 경우 Fiddler의 스냅숏을 보여 줍니다.

Fiddler 도구 결과

Fiddler 데이터가 나타내듯이 요청된 항목 수가 44에서 11로 크게 줄어들었습니다. 알아둘 중요한 점은 요청 수는 페이지가 요청되는 방식에 따라 달라질 수 있다는 것입니다. 브라우저에서 새로 고침 단추를 사용하는 경우 항목의 캐시된 로컬 버전이 있는지 여부에 관계없이 모든 항목이 다시 요청될 수 있습니다. 반대로, 링크나 바로 가기를 사용하여 페이지로 이동하여 페이지가 요청되는 경우에는 캐시되지 않은 항목만 요청됩니다.

Fiddler 데이터에 표시된 다른 사항은 브라우저가 로컬 캐시에 이미 있는 마스터 페이지의 다른 이미지를 서버에 요청하는 것입니다. 304 응답 코드가 이를 나타냅니다. 즉, 브라우저는 조건부로 항목을 요청합니다. 304 응답은 서버의 버전이 클라이언트의 버전에서 수정되지 않았으므로 다시 다운로드될 필요가 없음을 의미합니다. 파일이 네트워크를 통해 다운로드되지 않는 경우에도 로컬 복사본이 최신인지 확인하기 위해 서버 왕복이 여전히 생성됩니다. 지역적으로 분산된 환경에서 서버 왕복은 비용이 많이 들므로 목표는 가능한 한 왕복을 줄이는 것입니다. 0이 아닌 캐싱 지시문이 나머지 항목(서버에서 항상 반환되는 페이지 제외)에 각각 추가되면 이 목표를 달성할 수 있습니다. BLOB 캐시 기능은 이 캐싱 지시문을 추가합니다.

캐시가 사용될 웹 응용 프로그램의 Web.config 파일을 사용하여 BLOB 캐시를 구성합니다. 메모장 등의 텍스트 편집기에서 Web.config 파일을 열고 BlobCache 항목을 검색합니다. 기본적으로 이 항목은 다음과 같습니다.

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js)$ " maxSize="10" enabled="false"/>

BlobCache 요소에서 사용된 특성에는 다음과 같은 의미가 있습니다.

location 캐시된 항목이 저장될 웹 서버 하드 디스크 드라이브의 위치를 나타냅니다.
path 캐시될 파일의 형식에 대한 정규식 표현입니다.
maxSize ** **사용할 수 있는 캐시의 크기(GB)입니다.
enabled BLOB 캐시를 사용하려면 true로 설정합니다.

기본적으로 포함되지 않는 다음 추가 특성은 개별 항목에 대한 캐싱 만료 값을 설정하는 데 필요합니다.

max-age 클라이언트 컴퓨터에서 항목이 캐시되는 시간(초)입니다.

MaxAge 특성을 0이 아닌 값으로 설정하면 캐시 가능한 항목에 캐시 만료 값이 연결되므로 브라우저에서 더 이상 항목을 다운로드하거나 최신 버전을 갖고 있는지 확인할 필요가 없습니다. 예를 들어 캐싱을 사용하고 항목을 저장하기 위해 웹 서버에 최대 100MB를 할당하려는 경우 항목이 하루에 한 번 만료되고 캐시된 미리 정의된 형식 외에 .htc 파일도 캐시되어야 하는 요구 사항을 지원하려면 다음 BlobCache 특성을 지정합니다.

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js|htc)$ " maxSize="100" max-age="86400" enabled="true"/>

팜의 모든 웹 서버에서 Web.config 파일을 위와 같이 변경해야 합니다. 대부분의 경우 BLOB 캐시는 즉시 작동하기 시작하지만 변경을 구현할 때 iisreset 명령을 사용하는 것이 가장 안전합니다. 다음 스크린샷에서는 이전에 보여 준 동일한 페이지 요청에 대한 Fiddler 데이터를 보여 줍니다. 단 여기에서는 BLOB 캐시가 설명한 대로 사용됩니다.

Fiddler 도구 결과

이제 /SiteCollectionImages 라이브러리의 모든 항목에 대한 HTTP 상태 코드는 성공적으로 다운로드되었음을 나타내는 200입니다. 또한 이러한 항목에 하루(8,400초) 동안 만료되지 않도록 지정하는 캐싱 지시문이 모두 연결되어 있습니다. 페이지가 다시 요청되는 경우 이미지가 다시 요청되지 않는 것을 Fiddler에서 확인할 수 있습니다. 페이지에서 총 서비스 요청 수가 44에서 3으로 줄어들며 이 중 2개는 웹 서버와 클라이언트 응용 프로그램 간에 발생하는 NTLM 인증 협상에서 발생한 것입니다. 다음 그림에서는 페이지가 다시 요청되는 경우의 Fiddler 데이터를 보여 줍니다.

Fiddler 도구 결과

또한 BLOB 캐시로 작업할 때 다음을 고려합니다.

각 웹 서버에서 Web.config 파일을 업데이트해야 하기 때문에 구성하는 데 노력이 추가로 필요합니다. 그러나 이러한 노력을 할 만한 혜택을 얻을 수 있습니다.
사이트 콘텐츠를 조사하고 캐시에서 처리되어야 하는 다른 파일 형식이 있는지 확인합니다. .htc 파일이 좋은 예입니다. .htc 파일은 대부분의 게시 사이트에서 사용되기 때문에 캐시되는 파일 형식의 목록에 이 파일을 추가해야 합니다.
BLOB 캐시는 SharePoint 라이브러리에 저장된 항목에서만 작동합니다. 다른 원본의 콘텐츠를 캐시할 때는 BLOB 캐시를 사용할 수 없습니다.
일부 목록은 익명 사용자에 대해 기본적으로 작동하지 않습니다. 사이트에 액세스하는 익명 사용자가 있는 경우 다음 목록에 대한 사용 권한을 수동으로 구성하여 목록의 항목이 캐시되게 해야 합니다.
- 마스터 페이지 갤러리
- 스타일 라이브러리

BLOB 캐시로 작업할 때 명심해야 할 두 가지 구성 옵션이 있습니다. 첫 번째 옵션은 BLOB 캐시를 지우는 것과 관련이 있습니다. 특정 사이트에 대해 캐시를 지워야 하는 경우 해당 사이트 모음으로 이동하고 사이트 작업…사이트 설정…모든 사이트 설정 수정 메뉴를 클릭합니다. 사이트 모음 관리 작업의 목록에서 사이트 모음 개체 캐시 링크를 클릭합니다. 디스크 기반 캐시 다시 설정 섹션에서 이 서버에서 강제로 디스크 기반 캐시 다시 설정 확인란을 선택한 다음 확인 단추를 클릭합니다.

SharePoint 팜에서 웹 가든을 사용할 계획인 경우 BLOB 캐시가 일관성 없게 작동할 수 있는 문제를 알고 있어야 합니다. 서버 팜에서 웹 가든이 2개 이상 구성되어 있으면 둘 중 하나만 BLOB 캐시를 관리하는 데 필요한 잠금을 얻을 수 있기 때문에 문제가 발생합니다. 이에 따라 BLOB 캐시가 간헐적으로만 작동하는 것처럼 보일 수 있습니다. BLOB 캐시를 성공적으로 사용할 수 있는지 여부는 요청을 처리하는 스레드에 따라 달라집니다.

IIS 압축

이전 버전의 SharePoint 제품 및 기술과 달리, IIS 압축은 이제 SharePoint 제품 및 기술을 설치할 때 자동으로 설정됩니다. 몇몇 사용자가 사이트를 방문한 후 웹 서버에서 %WINDIR%\IIS Temporary Compressed Files 디렉터리를 확인하여 압축이 작동하고 있는지 확인할 수 있습니다. 이 디렉터리에 여러 파일이 포함되어야 합니다. 여러 파일이 포함되어 있으면 정적 파일이 요청되었고 IIS에서 해당 파일의 복사본을 압축하고 로컬 드라이브에 저장한 것입니다. 해당 파일이 다시 요청되면 동일한 사용자이든 아니든 간에 압축된 버전의 파일이 이 폴더에서 직접 제공됩니다. 동적 파일도 압축될 수 있지만 항상 즉시 압축됩니다. 복사본은 로컬 웹 서버에 유지되지 않습니다.

압축을 통해 대역폭이 크게 절약될 수 있습니다. 예를 들어 core.js 파일은 모든 SharePoint 페이지에 포함됩니다. 이 파일이 압축되지 않으면 크기가 257KB이지만 압축된 후에는 IIS 압축에 맞게 추가로 조정하지 않고도 크기가 54KB에 불과합니다. core.js는 사용자가 사이트를 처음 방문한 후 캐시되어야 하지만 이 예를 통해 대역폭이 적은 시나리오에서 압축이 얼마나 큰 도움이 되는지를 알 수 있습니다.

SharePoint 제품 및 기술이 설치될 때 정적 파일 형식 .htm, .html 및 .txt를 압축하도록 IIS가 구성됩니다. IIS에서는 동적 파일 형식 .asp 및 .exe도 압축합니다. 해당 구현에서 널리 사용되는 파일 형식을 조사하여 추가 파일 형식을 압축하는 것이 도움이 될 수 있습니다. 예를 들어 정적 파일 형식 .css 및 .js를 압축하거나 동적 파일 형식 .axd 및 .aspx를 압축하는 것이 적합할 수 있습니다.

정적 또는 동적 파일 형식을 압축될 형식의 목록에 추가하려면 각 웹 서버에서 %SystemDrive%\Inetpub\AdminScripts 폴더에 기본적으로 있는 adsutil.vbs 파일을 사용합니다. 다음 예제에서는 압축된 정적 파일 형식의 목록에 css 및 js 파일을 포함하는 Microsoft Windows Server 2003을 보여 줍니다.

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcFileExtensions "htm" "html" "txt" "css" "js"
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcFileExtensions "htm" "html" "txt" "css" "js"

다음 예제에서는 동적 파일 형식의 목록에 .aspx 및 .axd 파일을 포함하는 방법을 보여 줍니다.

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "exe" "axd" "aspx"
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "exe" "axd" "aspx"

압축된 파일 형식을 변경할 때 압축에 적합한 파일만 포함해야 합니다. 예를 들어 .jpg 파일의 경우 파일 형식이 기본적으로 이미 압축되어 있기 때문에 압축에 적합하지 않습니다. 또한 docx, xlsx 및 pptx와 같은 2007 Microsoft Office 시스템 파일 형식은 서버에서 직접 제공되지 않기 때문에 압축에 적합하지 않습니다. 이러한 파일은 Microsoft Office 콘텐츠에 대한 다양한 통합된 최종 사용자 환경을 관리하는 데 사용되는 여러 가지 ISAPI 필터를 통해 라우트됩니다. 또한 2007 Microsoft Office 시스템에서 이러한 파일 형식은 기본적으로 압축되어 있습니다.

압축된 파일 형식을 제어하는 것 외에도 동적 파일 형식에 사용되는 압축 수준도 제어할 수 있습니다. 사용되는 압축량은 0에서 10까지의 단위로 나타냅니다. 압축 수준이 높을수록 파일 크기가 작아집니다. 그러나 압축 수준이 높을수록 CPU 사용량도 늘어나는 단점이 있으므로 더 작은 파일을 만들려면 압축 시 CPU 사용률이 증가합니다. IIS 압축을 사용하는 경우 압축 수준 0을 사용하도록 구성됩니다. 지금까지 SharePoint 제품 및 기술의 이상적인 압축 수준은 9입니다. 압축 수준을 변경하려면 이 문서에서 이전에 설명한 adsutil.vbs 스크립트 파일을 사용하십시오. 다음 예제에서는 압축 수준을 9로 변경하는 방법을 보여 줍니다.

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel "9"
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel "9"

참고

정적 파일의 압축은 이 설정을 통해 변경되지 않습니다.

자세한 내용은 HTTP 압축 사용(IIS 6.0) (영문)(https://go.microsoft.com/fwlink/?linkid=108705&clcid=0x412)을 참조하십시오.

BLOB 캐시와 IIS 압축 결합

BLOB 캐시를 사용하면 사용자가 SharePoint 사이트를 검색할 때 네트워크를 통해 전송되는 파일과 서버 왕복의 수를 크게 줄일 수 있습니다. BLOB 캐시와 함께 압축을 사용하면 클라이언트에 전송되는 파일에 대한 트래픽도 줄어듭니다. 둘을 결합하여 네트워크 트래픽과 네트워크 및 서버 리소스에 대한 경합을 크게 줄일 수 있습니다.

이 문서의 다운로드

이 항목은 다운로드 가능한 다음 문서에도 포함되어 있어 더 쉽게 읽고 인쇄할 수 있습니다.

Office SharePoint Server 2007 계획 및 아키텍처, 제2부

사용 가능한 문서의 전체 목록은 다운로드 가능한 Office SharePoint Server 2007 관련 콘텐츠 (영문)를 참조하십시오.

참고 항목

개념

WAN용 사용자 지정 웹 파트 최적화
Office Outlook 2007 및 Office Groove 소프트웨어로 Office SharePoint Server 글로벌 솔루션 확장
Office SharePoint Server에 대해 지원되는 글로벌 솔루션

WAN 환경에 맞게 Office SharePoint Server 최적화

WAN에 대한 토폴로지 디자인

콘텐츠 크롤링을 위한 토폴로지 최적화

로컬 콘텐츠 크롤링 전용 웹 서버 구성

원격 팜 크롤링 전용 웹 서버 구성

쿼리 성능을 위한 최적화

지리적으로 팜 서버 분리

콘텐츠 크롤링 프로세스 최적화

콘텐츠 원본에 대한 크롤링 조정

크롤링 빈도 구성과 전체 및 증분 크롤링 조정

크롤링 설정 구성

검색 시간 제한 설정

크롤러 영향 규칙

WAN 가속기 및 기타 타사 도구

WAN 가속기

오프로드 및 캐시 장치

클라이언트 솔루션

데이터 복제, 멀티 마스터 동기화 및 구성 관리

복수 팜 관리 및 보고

바이트 수준 또는 하드웨어 기반 복제

더욱 빠른 다운로드를 위한 페이지 디자인

페이지 요소

페이지 다운로드 최적화

BLOB 캐시

IIS 압축

64비트 하드웨어

웹 가든 설정

페이지에서 보호된 항목 최소화

이미지 수 및 크기 최소화

core.js 다운로드 지연

목록 보기 페이지 최적화

WAN 환경에 맞게 캐싱 최적화

BLOB 캐시

IIS 압축

BLOB 캐시와 IIS 압축 결합

이 문서의 다운로드

참고 항목

개념

추가 리소스