|
| |
| Sun Java System Calendar Server 관리 설명서 | |
19장
Calender Server 성능 조정Sun Java™ System Calendar Server의 성능을 향상시키려면 다음 옵션을 사용할 것을 고려하십시오.
LDAP 디렉토리 서버 색인Calendar Server가 LDAP 디렉토리 서버에 액세스할 때 성능을 향상시키려면 다음 속성을 위한 LDAP 구성 파일에 색인을 추가합니다.
- icsCalendar 속성은 달력 사용자 또는 자원의 기본 달력을 검색하는 데 사용됩니다. 존재(pres), 일치(eq) 및 하위 문자열(sub) 색인 유형을 지정합니다.
- icsCalendarOwned 속성은 LDAP CLD 플러그 인이 활성화되어 있을 때 가입 작업을 검색하는 데 사용됩니다. 존재(pres), 일치(eq) 및 하위 문자열(sub) 색인 유형을 지정합니다. DWP 환경의 달력 검색 성능 향상을 참조하십시오.
- mail 및 mailAlternateAddress 속성은 사용자의 기본 및 대체 전자 메일 주소를 지정합니다. 필수 mail 속성 및 전자 메일 별칭(mailalternateaddress 속성)을 참조하십시오.
주 Directory Server 설치(comm_dssetup.pl) 스크립트를 실행하여 Directory Server 5.x를 구성하면 스크립트는 icsCalendar 및 icsCalendarOwned 속성에 대한 색인을 추가합니다.
디렉토리 서버 색인 추가에 대한 자세한 내용은 다음 웹 사이트의 Directory Server Configuration, Command, and File Reference를 참조하십시오.
http://docs.sun.com/db/coll/S1_ipDirectoryServer_51
DWP 환경의 달력 검색 성능 향상달력 데이터베이스가 여러 백엔드 서버에 있는 경우, 즉 DWP 환경에서는 달력 검색에 시간이 많이 걸릴 수 있습니다. 먼저 LDAP 항목을 보고 달력이 상주하는 DWP 호스트를 직접 찾는 것이 더 빠를 수 있습니다.
달력 검색에서 먼저 LDAP 디렉토리를 보고 다음으로 달력 데이터베이스를 보도록 하려면 ics.conf 파일의 다음 매개 변수가 표시된 기본값과 같이 설정되어 있는지 확인합니다.
service.calendarsearch.ldap = "yes"
LDAP 디렉토리의 달력 검색이 활성화된 경우 다음과 같은 방법으로 검색 성능을 향상시킬 수 있습니다.
icsCalendarOwned 속성 색인 사용
LDAP 디렉토리 서버의 달력 검색 성능을 향상시킬 수 있는지 여부를 확인하려면 다음 LDAP 명령을 사용합니다.
ldapsearch -b "base"
"(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"여기서 base는 Calendar Server의 사용자와 자원 데이터가 있는 디렉토리 서버의 LDAP 기본 DN이며, user는 사용자가 Calendar Express가입->달력 검색 대화 상자에 입력할 수 있는 값입니다.
테스트 결과 60,000개의 항목을 검색할 경우 icsCalendarOwned 속성에 대한 색인을 사용하지 않으면 50-55초가 걸립니다. 그러나 색인을 사용하면 1-2초 밖에 걸리지 않습니다.
Directory Server에서 Solaris 운영 체제에 대해 다음 명령을 사용하여 icsCalendarOwned 속성에 대한 색인을 만듭니다.
server5/bin/slapd db2index -D slapd-serverID
-t icsCalendarOwned: eq,pres,sub:2.16.840.1.113730.3.3.2.11.1여기서 slapd-serverID는 slapd-serverID 디렉토리에 대한 전체 경로입니다.
nsSizeLimit 및 nsLookthroughLimit 매개 변수 설정
LDAP 디렉토리 서버 구성의 nsSizeLimit 및 nsLookthroughLimit 매개 변수는 검색이 제대로 완료될 수 있을 만큼 커야 합니다.
이 두 매개 변수 값이 제대로 설정되어 있는지 확인하려면 다음 명령을 사용합니다.
ldapsearch -b "base"
"(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"여기서 base는 Calendar Server의 사용자와 자원 데이터가 있는 디렉토리 서버의 LDAP 기본 DN이며, user는 사용자가 Calendar Express 가입->달력 검색 대화 상자에 입력할 수 있는 값입니다.
LDAP 서버가 오류를 반환하면 nsSizeLimit 또는 nsLookthroughLimit 매개 변수가 충분히 크게 설정되지 않았기 때문일 수 있습니다. 다음 지침에 따라 이 두 매개 변수를 설정하십시오.
CLD 캐시 옵션 활성화
LDAP 검색을 최적화하려면 다음과 같이 CLD 캐시 옵션을 설정합니다("yes"가 기본값).
caldb.cld.cache.enable = "yes"
또한 CLD 캐시 옵션 사용을 참조하십시오.
LDAP 데이터 캐시 옵션 사용LDAP 데이터 캐시 옵션은 LDAP 디렉토리 서버가 완결된 데이터의 가용성이 지연되도록 구성된 경우에도 완결 즉시 LDAP 데이터를 사용할 수 있도록 합니다.
예를 들어, 사이트에서 마스터/슬레이브 LDAP 구성을 배포하여 Calendar Server가 슬레이브 LDAP 디렉토리 서버를 통해 마스터 LDAP 디렉토리에 액세스하고 이 때문에 완결된 LDAP 데이터의 가용성이 지연될 경우 LDAP 데이터 캐시를 사용하면 Calendar Server 클라이언트에 정확한 LDAP 데이터를 제공할 수 있습니다.
이 절은 다음 내용으로 구성되어 있습니다.
LDAP 데이터 캐시 사용을 위한 고려 사항
다음 지침을 사용하여 사이트에 LDAP 데이터 캐시를 구성해야 할 것인지 여부를 결정합니다.
- 사용자 사이트에서 Calendar Server가 완결한 LDAP 데이터의 가용성이 지연되지 않고 마스터(또는 루트) LDAP 디렉토리 서버에 직접 액세스할 경우에는 LDAP 데이터 캐시를 구성할 필요가 없습니다. local.ldap.cache.enable 매개 변수는 기본값인 "no"로 설정되어 있어야 합니다.
- 사이트에서 마스터/슬레이브 LDAP 구성을 배포하고 Calendar Server가 슬레이브 LDAP 디렉토리 서버를 통해 마스터 LDAP 디렉토리에 액세스하여 완결된 LDAP 데이터의 가용성이 지연되는 경우에는 최종 사용자가 가장 최신 데이터를 얻을 수 있도록 LDAP 데이터 캐시를 구성합니다.
마스터/슬레이브 LDAP 구성
마스터/슬레이브 LDAP 구성에는 하나의 마스터(루트) 디렉토리 서버와 하나 이상의 슬레이브(소비자 또는 복제) 디렉토리 서버가 포함됩니다. Calendar Server는 직접 또는 슬레이브 디렉토리를 통해 마스터 LDAP 디렉토리에 액세스할 수 있습니다.
이러한 두 번째 유형의 구성에서는 슬레이브 디렉토리 서버에 완결된 LDAP 데이터의 가용성이 지연되기 때문에 정확하지 않은 LDAP 데이터에 문제가 발생할 수 있습니다.
예를 들어, Calendar Server는 LDAP 데이터 변경을 완결하지만 각 슬레이브 디렉토리 서버를 업데이트하는 마스터 디렉토리 서버의 지연 때문에 일정 시간 동안 새 데이터를 사용할 수 없습니다. 이후의 Calendar Server 클라이언트 작업에서는 이전 LDAP 데이터를 사용하고 이전 보기를 표시합니다.
슬레이브 디렉토리 서버 업데이트 시 지연이 짧은(단 몇 초에 불과한) 경우에는 클라이언트에서 문제가 발생하지 않을 수 있습니다. 그러나 지연 시간이 몇 분 또는 몇 시간으로 길어진다면 클라이언트에서는 지연되는 시간 동안 부정확한 LDAP 데이터를 표시하게 됩니다.
표 19-1에서는 Calendar Server가 슬레이브 LDAP 디렉토리 서버를 통해 마스터 LDAP 디렉토리 서버에 액세스하는 마스터/슬레이브 LDAP 서버 구성의 지연에 의해 영향을 받는 LDAP 속성을 나열합니다.
최종 사용자들에게 최신 LDAP 데이터를 제공하려면 LDAP 데이터 캐시 및 LDAP 데이터 캐시 구성 매개 변수에 설명된 대로 LDAP 데이터 캐시를 구성합니다.
LDAP 데이터 캐시
LDAP 데이터 캐시는 마스터 디렉토리 서버가 각 슬레이브 디렉토리 서버를 업데이트하지 않았을 때에도 Calendar Server 클라이언트에 최신 LDAP 데이터를 제공함으로써 마스터/슬레이브 LDAP 구성 문제를 해결합니다.
LDAP 데이터 캐시가 활성화된 경우 Calendar Server는 완결된 LDAP 데이터를 캐시 데이터베이스(ldapcache.db 파일)에 기록합니다. 기본적으로 LDAP 캐시 데이터베이스는 cal_svr_base/var/opt/SUNWics5/csdb/ldap_cache 디렉토리에 있지만, 필요할 경우 다른 위치를 구성할 수 있습니다.
클라이언트가 단일 사용자의 LDAP 데이터를 변경하면 Calendar Server는 개정된 데이터를 LDAP 캐시 데이터베이스와 슬레이브 디렉토리 서버에 기록합니다. 이후의 클라이언트 작업에서는 캐시 데이터베이스에서 LDAP 데이터를 검색합니다. 이러한 데이터 검색은 단일 사용자에 대한 다음 작업에 적용됩니다.
따라서 LDAP 데이터 캐시 데이터베이스는 다음을 제공합니다.
- 단일 시스템 상의 프로세스 간 데이터 일관성 데이터 캐시 데이터베이스는 다중 프로세서 시스템의 모든 Calendar Server 프로세스에서 사용할 수 있습니다.
- 사용자 세션 간의 데이터 지속성 데이터 캐시 데이터베이스는 영구적이며 새로 고칠 필요가 없습니다. LDAP 데이터 캐시 항목의 지속 시간(TTL)과 각 데이터베이스 정리 사이의 간격을 구성할 수 있습니다. 자세한 내용은 LDAP 데이터 캐시 구성 매개 변수를 참조하십시오.
제한 사항
LDAP 데이터 캐시는 다음을 제공하지 않습니다.
- 항목의 목록이 예상되는 검색을 위한 캐시 읽기. 예를 들면 회의 참석자 검색 등이 이에 속합니다. 이러한 유형의 검색에는 LDAP 지연이 적용됩니다. 가령 LDAP 검색 옵션이 활성화되고 새 달력을 만든 후 지연 기간 내에 검색을 수행하면 새로 만든 달력은 달력 검색에 나타나지 않습니다.
- 다수의 프런트엔드 서버에 대한 캐시 읽기 및 쓰기. 각 프런트엔드 서버에 있는 자체 캐시에서는 다른 캐시의 데이터를 인식하지 못합니다.
- 항상 같은 서버에 로그인하지 않는 사용자를 처리하는 능력. 그러한 사용자는 각 서버의 캐시에 각각 다른 LDAP 데이터를 생성합니다.
LDAP 데이터 캐시 구성 매개 변수
표 19-2에서는 LDAP 데이터 캐시를 위한 ics.conf 파일의 구성 매개 변수에 대해 설명합니다.
주의
Calendar Server 또는 Calendar Server를 실행 중인 서버가 제대로 종료되지 않은 경우에는 ldap_cache 디렉토리에 있는 모든 파일을 수동으로 삭제하여 이후에 다시 시작할 때 문제가 될 수 있는 데이터베이스 손상을 방지해야 합니다.
CLD 캐시 옵션 사용CLD 플러그 인과 함께 사용하는 경우에는 ics.conf의 다음 구성 매개 변수를 "yes"(각 매개 변수의 기본값)로 설정합니다.
caldb.cld.cache.enable = "yes"
이 매개 변수는 CLA 캐시 옵션을 활성화합니다. 이 캐시는 달력 사용자에 대한 DWP 호스트 서버 정보(icsDWPHost LDAP 속성)를 저장하며 따라서 LDAP 디렉토리 서버에 대한 호출이 감소됩니다.
설정할 수 있는 다른 CLD 캐시 옵션 매개 변수는 다음과 같습니다.
이 매개 변수와 기타 관련 ics.conf 매개 변수에 대한 자세한 내용은 부록 E, "Calendar Server 구성 매개 변수"를 참조하십시오.
세션 데이터베이스를 위한 메모리 기반 파일 시스템 사용ics.conf 파일에서 다음 매개 변수를 설정하여 세션 데이터베이스의 메모리 기반 파일 시스템(tmpfs)을 구성하면 Solaris 운영 체제의 성능을 향상시킬 수 있습니다.
local.instance.use.tmpfs to "true"
tmpfs 파일 시스템은 service.http.sessiondir.path 및 service.admin.sessiondir.path 매개 변수의 값을 기반으로 오버레이됩니다.
자세한 내용은 Solaris 설명서의 tmpfs(7FS) 및 mount_tmpfs(1M) 설명서 페이지를 참조하십시오.
http://docs.sun.com/db/prod/solaris 및 http://docs.sun.com/db/prod/solaris?l=ko
여러 CPU에 걸쳐 로드 균형 조정 사용서버에 CPU가 여러 개인 경우 Calendar Server는 기본적으로 HTTP 서비스(cshttpd 프로세스) 및 분산 데이터베이스 서비스(csdwpd 프로세스)를 분산시킵니다.
service.http.numprocesses 및 service.dwp.numprocesses 매개 변수는 각 서비스를 위해 실행되는 실제 프로세스 수를 결정합니다. 기본적으로 이 두 매개 변수는 설치하는 동안 서버의 CPU 수로 설정되지만 값을 재설정할 수 있습니다. 예를 들어, CPU가 8개인 서버인 경우 cshttpd 및 csdwpd 프로세스를 4개의 CPU에서만 실행하려면 매개 변수를 다음과 같이 설정하면 됩니다.
service.http.numprocesses="4"
service.dwp.numprocesses="4"로드 균형 조정을 비활성화하려면 service.loadbalancing 매개 변수를 ics.conf 파일에 추가하고 "no"로 설정합니다. 변경 내용을 적용하려면 Calendar Server를 다시 시작합니다.
시간 초과 값 사용Calendar Server 성능은 다양한 ics.conf 매개 변수의 시간 초과 값을 사용하여 조정할 수 있습니다.
다음과 같은 시간 초과 유형이 있습니다.
ics.conf 매개 변수 편집에 대한 자세한 내용은 ics.conf 구성 파일 편집을 참조하십시오.
csadmind의 시간 초과 값
표 19-3에서는 관리(csadmin) 서비스에서 사용하는 ics.conf 파일의 Calendar Server 시간 초과 매개 변수를 설명합니다.
최종 사용자의 HTTP 시간 초과 값
표 19-4에서는 최종 사용자에게 적용되는 ics.conf 파일의 Calendar Server HTTP 시간 초과 매개 변수를 설명합니다.
GSE 대기열 시간 초과 값
다음 ics.conf 파일 매개 변수는 Calendar Server가 그룹 예약 엔진(GSE) 대기열에서 들어오는 작업을 스캔하기 전에 기다리는 시간을 초 단위로 지정합니다.
gse.belowthresholdtimeout = "3"
할당된 최대 스레드보다 많은 작업이 대기열에 있으면 마지막 스레드는 항상 대기열을 다시 스캔합니다. 따라서 이러한 설정은 작업의 수가 할당된 최대 스레드보다 적을 때만 적용됩니다.
기본값은 "3"입니다. 이 숫자를 증가시키면 서버가 대기열을 검색하는 빈도가 감소하고 전체적인 성능이 향상될 수 있습니다. 하지만 이벤트의 크기가 증가하여 대기열이 너무 커지면 시간을 줄여 대기열의 처리 속도를 높일 수 있습니다. 그러면 전반적인 성능은 저하되지만 이벤트 업데이트 속도는 빨라집니다.
보기 새로 고침 옵션 사용Calendar Express 최종 사용자는 보기 새로 고침 옵션을 사용하면 Calendar Server 데이터베이스에서 업데이트하기보다 브라우저 캐시의 달력 데이터를 사용하여 보기를 새로 고침으로써 성능이 향상됩니다.
보기 새로 고침 옵션을 활성화하려면 ics.conf 파일에서 다음 매개 변수를 "yes"로 설정해야 합니다.
browser.cache.enable = "yes"
이 매개 변수를 재설정하면 Calendar Server를 중지한 다음 다시 시작해야 새 값이 적용됩니다.
사이트에 보기 새로 고침 옵션이 구성되면 Calendar Express는 View 탭의 모든 달력 보기에 보기 새로 고침을 표시합니다.
사용자가 보기 새로 고침을 누르면 Calendar Express가 달력 데이터베이스에서 업데이트를 요청하기 전에 먼저 보기의 달력 데이터가 변경되었는지 여부를 확인합니다. 데이터가 변경되지 않았으면 Calendar Express는 브라우저 캐시의 정보를 사용하여 보기를 새로 고칩니다. 따라서 달력 데이터베이스에 대한 불필요한 요청을 피할 수 있으며, 이렇게 하면 많은 수의 이벤트 또는 태스크가 있는 달력일 경우 특히 성능 향상에 도움이 됩니다.
이벤트 또는 태스크가 변경된 경우에는 Calendar Express가 달력 데이터베이스에서 업데이트를 요청하여 보기를 새로 고칩니다. 또한 사용자는 보기 새로 고침 옵션을 사용함으로써 Calendar Express가 항상 최신 달력 데이터를 표시하도록 할 수 있습니다.
Calendar Express 도구 모음의 다시 그리기 옵션 비활성화도구 모음의 다시 그리기 옵션을 사용하면 사용자가 새로 고침을 누를 때 Calendar Express 보기가 새로 고쳐집니다. 그러나 이 옵션을 사용하면 Calendar Server가 도구 모음을 위한 XML 및 XSLT 변환을 수행하여 보기를 새로 고치기 때문에 성능에 문제가 생길 수 있습니다.
도구 모음의 다시 그리기 옵션을 비활성화하려면 ics.conf 파일의 다음 매개 변수를 "no"로 설정합니다.
ui.toolbar.repainting.enable="no"
ui.toolbar.repainting.enable을 "no"로 설정할 경우 사용자가 어느 보기에서나 새로 고침을 누르면 기본 보기로 돌아갈 수 있습니다.
ui.toolbar.repainting.enable을 "no"로 설정하면 Calendar Express가 도구 모음을 위한 XML 및 XSLT 변환을 수행하지 않기 때문에 성능이 향상됩니다.
브라우저 캐시 옵션(browser.cache.enable 매개 변수)을 "yes"로 설정하면 도구 모음의 다시 그리기 옵션이 사용되지 않습니다.
클라이언트 브라우저에서 XSL 렌더링Calendar Server는 XSLT 프로세싱을 최종 사용자의 브라우저로 다운로드하여 클라이언트측 렌더링을 수행합니다. 이렇게 하면 Calendar Server가 수행해야 하는 프로세싱이 감소됩니다. Calendar Server는 브라우저가 XSLT 프로세싱을 렌더링할 수 있는 기능이 있는 경우에만 XSLT를 다운로드합니다. 현재 릴리스에서 이 기능은 Internet Explorer 6.0에만 적용됩니다.
테스트 결과 클라이언트측 렌더링을 통해 인터페이스(UI)의 확장성을 4-6배까지 향상시킬 수 있는 것으로 나타났습니다. 즉, Calendar Server는 CPU 성능을 심각하게 저하시키지 않으면서 4-6배의 동시 최종 사용자를 지원할 수 있습니다.
ics.conf 파일의 다음 매개 변수가 클라이언트측 렌더링(현재 Internet Explorer 6.0 이상만 해당됨)을 제어합니다.
render.xslonclient.enable="yes"
기본적으로 이 매개 변수는 "yes"로 설정됩니다. 클라이언트측 렌더링을 사용하지 않으려면 이 매개 변수를 "no"로 설정하고 Calender Server를 다시 시작합니다.