기타 성능 및 용량 계획 요소(Office SharePoint Server)
업데이트 날짜: 2009년 4월
적용 대상: Office SharePoint Server 2007
마지막으로 수정된 항목: 2009-04-17
이 섹션에서는 배포를 계획할 때 고려해야 하는 추가적인 요소에 대해 설명합니다.
환경적 요소
콘텐츠 쿼리 웹 파트
환경적 요소
네트워크 고려 사항
네트워크 보안
인증
사용자 지정 코드 개발
네트워크 구성
네트워크 구성은 설치된 Office SharePoint Server 또는 Windows SharePoint Services의 성능에 큰 영향을 줍니다. 성능에 영향을 줄 수 있는 일반적인 네트워크 구성 요소는 다음과 같습니다.
NIC(Network Interface Card)
NIC 설정 가능하면 항상 기가비트 네트워크 카드를 사용해야 합니다. 셀프 스위칭 카드(100MB/1GB)가 있는 경우에는 항상 오버라이드를 설정하여 1기가비트를 사용해야 합니다.
인바운드/아웃바운드 높은 트래픽이 예상되는 시나리오에서는 인바운드 트래픽과 아웃바운드 트래픽을 별도의 NIC로 처리하는 것이 좋습니다.
**스위치 **스위치를 통해 네트워크를 실행하는 경우에는 GB 스위치를 사용하고 있고 인바운드/아웃바운드 채널의 수가 동일한지 확인하십시오.
**라우터 **라우터가 GB 인프라에 구성되어 있는지 확인하십시오.
도메인 컨트롤러 도메인 컨트롤러(DC)가 응답할 수 있는 속도보다 더 빠른 속도로 요청을 받는 경우 SharePoint 환경에서 인증 프로세스가 성능 병목 현상의 원인이 될 수 있습니다. NTLM과 같은 사용자 인증을 사용하는 환경에서는 웹 서버의 비율을 DC당 세 개로 유지하는 것이 좋습니다. 테스트를 통해 DC당 세 개의 웹 서버로 인증 부하를 겨우 처리할 수 있는 것으로 나타나면 최대 지원 한도인 DC당 네 개의 웹 서버까지 DC당 웹 서버 하나를 더 추가할 수 있습니다.
시스템을 프로덕션 환경으로 전환하기 전에 네트워크 구성을 철저하게 계획하고 테스트해야 한다는 점을 잊지 마십시오.
네트워크 토폴로지 권장 사항
팜 내 그리고 팜 간의 네트워크 연결을 계획하십시오. 대기 시간이 짧은 네트워크를 사용하는 것이 좋습니다.
다음 목록에 몇 가지 최상의 방법과 권장 사항을 제공되어 있습니다.
팜에 있는 모든 서버는 SQL Server 2005를 실행하는 서버에 대한 LAN 대역폭과 대기 시간이 있어야 합니다(최대 1밀리초(ms) 대기 시간).
SQL Server 2005를 실행하는 서버가 팜의 다른 구성 요소와 떨어져 원격으로 WAN 토폴로지에 배포되고 네트워크 대기 시간이 1ms를 넘는 환경에서의 Office SharePoint Server 2007 배포는 테스트되지 않았습니다. 따라서 이러한 WAN 토폴로지는 권장하지 않습니다.
SQL Server 2005 미러링 또는 SQL Server 2005 로그 전달을 사용하여 원격 사이트를 최신 상태로 유지할 계획이면 적절한 WAN 네트워크를 계획하십시오.
네트워크 보안
네트워크 보안에 대한 자세한 내용은 서버 팜 내 보안 통신 계획(Office SharePoint Server)을 참조하십시오.
인증
작업 환경에서 사용되는 인증 메커니즘은 시스템의 전체적인 성능에 점진적인 영향을 줍니다. 인증 성능에 영향을 주는 요소는 다음과 같습니다.
인증 공급자와 주고 받는 왕복 이동의 횟수와 속도
인증 공급자 처리 성능
Microsoft 테스트 결과, 인증 메커니즘의 속도 순서는 장 빠른 것에서부터 가장 느린 것 순으로 다음과 같습니다.
익명
Kerberos
NTLM
기본
폼
Office SharePoint Server 또는 Windows SharePoint Services와 함께 사용할 인증 공급자를 만들기로 선택한 경우에는 MSDN 문서 ASP.NET에서의 인증: 보안 지침 (영문)(https://go.microsoft.com/fwlink/?linkid=98743&clcid=0x412)에 있는 최상의 방법 지침을 따라야 합니다.
사용자 지정 코드 개발
이전 릴리스의 SharePoint Server에서 성능이 떨어지는 가장 흔한 원인은 SharePoint 플랫폼상에서 비효율적인 사용자 지정 기능이 개발되고 배포되었기 때문이었습니다. SharePoint를 위한 고객 기능을 개발할 때는 여러 가지 성능 수치를 모니터링해야 합니다. 여기에는 다음이 포함되며 이에 국한되지 않습니다.
SQL Server 왕복 핵심 페이지의 경우 SQL 왕복이 2-3회를 넘어가는 것은 좋지 않습니다. 과도한 왕복은 성능에 다음과 같은 악영향을 줍니다.
서버 쪽 처리 시간 증가로 인한 최종 사용자 응답 시간 증가
데이터베이스 서버에 걸리는 추가적인 부하로 인한 전체 시스템 처리량 감소
**SQL Server CPU 활용도 **MOSS 시스템이 정상적으로 유지되기 위해서는 데이터베이스 서버의 CPU 활용도가 상대적으로 낮게 유지되어야 합니다. SQL Server 2005 CPU 활용도가 평균적으로 60%를 넘으면 성능에 부정적인 영향을 줍니다. SQL CPU 활용도를 낮추기 위해 취할 수 있는 조치는 다음과 같습니다.
캐싱 전략 구현 – 웹 서버에서 데이터베이스 서버로의 전체적인 호출 수를 줄입니다.
원하는 데이터를 가장 효율적인 방법으로 반환하는 개체 메서드를 사용하도록 사용자 지정 코드 최적화(예: 목록에 인덱스 사용 등)
SQL 데이터베이스를 여러 실제 데이터베이스 서버에 배포
페이지 다운로드 크기 코드 크기를 최소한으로 유지하십시오. 페이지 크기가 조금만 커지더라도 매일 많은 사람이 그 페이지에 액세스할 경우 성능에 큰 영향을 줄 수 있습니다. 특히 사용량이 많은 시간에는 더욱 그렇습니다.
클라이언트 쪽 코드 효율성 최종 사용자 응답 시간의 약 50%는 반환된 코드를 클라이언트에서 처리하는 시간입니다. 사용자 지정 솔루션으로 인해 이 시간이 늘어날 경우에는 최종 사용자 응답 시간도 늘어나게 됩니다.
**AJAX 콜백 **AJAX 파트에서는 콜백 수와 각 콜백의 페이로드가 성능에 영향을 줍니다. 예를 들어 각 KPI는 결과를 반환하기 위해 세 번의 호출을 수행합니다. KPI 또는 다른 사용자 지정 코드를 페이지에서 여러 개 사용할 때는 페이지 성능을 반드시 테스트하십시오.
콘텐츠 쿼리 웹 파트
콘텐츠 쿼리 웹 파트는 Windows SharePoint Services 교차 목록 쿼리 메커니즘을 사용하여 SharePoint 사이트 모음에서 콘텐츠를 검색합니다. 다수의 목록을 포함하는 쿼리를 실행하도록 웹 파트가 구성되어 있으면 교차 목록 쿼리 메커니즘에서 예외가 발생할 수 있습니다.
기본적으로 교차 목록 쿼리는 목록이 1,000개로 제한되어 있습니다. 즉, 1,000개가 넘는 목록을 포함하고 있는 쿼리로 콘텐츠 쿼리 웹 파트를 구성하면 교차 목록 쿼리가 완료되지 않으며 웹 파트가 아무런 콘텐츠도 보여 주지 않습니다. 표시하지 않습니다. 이렇게 제한하는 이유는 SQL Server 2005의 과부하를 방지하기 위함입니다. 교차 목록 쿼리에 더 많은 목록이 포함되어 있을수록 쿼리가 요청하는 콘텐츠를 데이터베이스 서버가 반환하는 데 시간이 오래 걸립니다. 목록 수가 매우 많은 경우에는 데이터베이스 서버가 교차 목록 쿼리를 처리하는 데 집중하느라 다른 요청을 처리하지 않는 문제가 발생할 수 있습니다.
1,000개가 넘는 목록을 쿼리해야 하는 경우에는 작업으로 인해 발생하는 데이터베이스 부하가 용인되는 한도 내에서 목록 제한을 늘릴 수 있습니다. MaxListLimit 특성을 웹 파트의 ListsOverride 속성에 추가하면 됩니다. 예를 들어 목록 제한을 2,000으로 높이려면 ListsOverride 속성을 다음과 같이 설정합니다.
<Lists ServerTemplate="850" MaxListLimit="2000">
이 문서의 다운로드
이 항목은 다운로드 가능한 다음 문서에도 포함되어 있어 더 쉽게 읽고 인쇄할 수 있습니다.
사용 가능한 문서의 전체 목록은 다운로드 가능한 Office SharePoint Server 2007 관련 콘텐츠 (영문)를 참조하십시오.