SharePoint Server 2010에서 엔터프라이즈 관리되는 메타데이터의 용량 및 성능 예측

 

적용 대상: SharePoint Server 2010

마지막으로 수정된 항목: 2016-11-30

이 문서에서는 Microsoft SharePoint Server 2010에서 Managed Metadata Service의 크기 조정 및 성능 최적화와 관련된 권장 사항을 제공합니다. 또한 성능을 최대화하기 위해 서비스를 구성하고 서비스 응용 프로그램 데이터베이스의 구조를 결정하는 방법에 대한 모범 사례를 제공합니다.

이 문서의 정보를 통해 테스트를 거친 Managed Metadata Service의 성능 및 용량 한도를 파악할 수 있습니다. 이 정보를 참조하여 계획한 배포가 적절한 성능 및 용량 한도 범위 내에 포함되는지를 확인하십시오.

이 문서의 내용

• 테스트 팜 특성

• 테스트 결과 및 권장 사항

용량 관리 및 SharePoint Server 2010에 대해 계획을 세우는 방법에 대한 일반 정보는 SharePoint Server 2010의 용량 관리 및 크기 조정을 참조하십시오.

테스트 팜 특성

데이터 집합

일반적인 고객 데이터 집합을 시뮬레이트하는 기본 데이터 집합에 대해 먼저 테스트를 실행했습니다. 그런 후에 변수 하나를 변경하고 같은 테스트를 다시 실행하여 해당 변수의 변경이 성능에 주는 영향을 확인했습니다. 대부분의 경우에는 변수를 독립적으로 테스트했지만, 특정 주요 변수는 조합하여 테스트한 경우도 있었습니다.

기본 데이터 집합

기본 데이터 집합에는 다음 표에 나와 있는 데이터가 포함됩니다.

데이터	세부 정보
용어 집합 그룹	100
용어 집합	1,000(그룹당 10개)
관리되는 용어(엔터프라이즈 키워드 제외)	20,000(용어 집합당 20개)
엔터프라이즈 키워드	80,000
총 용어 수(관리되는 용어 및 엔터프라이즈 키워드 포함)	100,000
레이블	100,000(용어당 1개)
용어 레이블 길이	레이블당 250자

아래 그래프에는 기본 데이터 집합의 용어 수가 나와 있습니다.

이 테스트에서 모든 데이터 집합의 키워드에 대한 관리되는 용어 비율은 항상 4:1이었습니다.

작업량

Managed Metadata Services의 다양한 주요 특성이 서비스 성능에 잠재적 영향을 줄 수 있습니다. 이러한 특성은 다음과 같습니다.

• 서비스의 데이터 특성

  • 용어 레이블 길이

  • 용어 저장소당 용어 수

  • 용어 저장소당 용어 레이블 수

• 서비스의 부하 특성

  • 읽기/쓰기 혼합

• 용어 저장소 캐시 크기

• 데이터베이스 서버당 서비스 응용 프로그램 수

• 서비스 타이머 작업(콘텐츠 형식 허브, 콘텐츠 형식 구독자, 엔터프라이즈 메타데이터 사이트 데이터 업데이트, 분류 업데이트 스케줄러)의 성능

이 문서에 나와 있는 구체적인 용량 및 성능 테스트 결과는 실제 환경의 테스트 결과와 다를 수 있으며, 적절한 규모의 환경을 디자인하기 위한 시작점을 제공하기 위한 것입니다. 초기 시스템 디자인을 완료한 후 구성을 테스트하여 시스템이 사용자 환경의 Managed Metadata Service 구성 방식을 지원하는지 여부를 확인하십시오.

테스트 시나리오

각 테스트 시나리오에는 다음 테스트를 사용했습니다.

• 용어 만들기(쓰기 테스트)

  이 테스트에서는 기존 용어 집합에 용어를 만듭니다.

• 추천 단어 가져오기(읽기 전용 테스트)

  이 테스트에서는 키워드 필드의 추천 단어 검색에서 사용하는 것과 같은 한 자로 된 문자열로 시작하는 용어를 검색합니다.

• 일치 항목 가져오기(읽기 전용 테스트)

  이 테스트에서는 키워드 필드 또는 메타데이터 필드의 값 일치와 같이 제공된 문자열과 일치하는 용어를 검색합니다.

• 페이징을 통해 용어 집합의 하위 용어 가져오기(읽기 전용 테스트)

  이 테스트에서는 페이징을 통해 용어 집합의 하위 용어를 검색합니다.

• 용어 유효성 검사(읽기 전용 테스트)

  이 테스트에서는 키워드 필드 또는 메타데이터 필드의 값 유효성 검사와 같이 단일 용어의 유효성을 검사합니다.

테스트 혼합

쓰기 작업의 영향 테스트를 제외한 대부분의 테스트에서는 읽기 및 쓰기 작업 혼합을 사용했으며, 이러한 혼합은 아래 표에 나와 있습니다.

테스트	혼합 비율
용어 만들기	0.125%
추천 단어 가져오기	72.875%
일치 항목 가져오기	11%
페이징을 통해 용어 집합의 하위 용어 가져오기	5%
용어 유효성 검사	11%

"추천 단어 가져오기"는 가장 많이 사용되는 최종 사용자 작업이므로 테스트 혼합에서 높은 가중치가 부여되었습니다.

하드웨어, 설정 및 토폴로지

테스트 팜은 서버가 3대 포함된 팜으로, 웹 서버, 응용 프로그램 서버 및 데이터베이스 컴퓨터에 대해 각각 별도의 서버가 한 대씩 있습니다.

웹 서버 및 응용 프로그램 서버

웹 서버와 응용 프로그램 서버는 동일한 하드웨어를 사용하며, 아래 표에 나와 있는 대로 구성되었습니다.

구성 요소	웹 서버 및 응용 프로그램 서버 구성
프로세서	쿼드 코어 2개(각 2.33GHz)
RAM	8GB
운영 체제	Windows Server 2008(64비트)
시스템 드라이브 크기	300GB
네트워크 어댑터 수	2개
네트워크 어댑터 속도	초당 1기가비트
인증	Windows 기본
소프트웨어 버전	SharePoint Server 2010 참고 사용하는 버전에 따라 결과가 달라질 수 있습니다.
로컬로 실행되는 서비스	중앙 관리 Microsoft SharePoint Foundation 받는 전자 메일 Microsoft SharePoint Foundation 웹 응용 프로그램 Microsoft SharePoint Foundation Microsoft SharePoint Foundation 워크플로 타이머 서비스

데이터베이스 서버

데이터베이스 서버는 아래 표에 나와 있는 대로 구성되었습니다.

구성 요소	데이터베이스 서버 구성
프로세서	쿼드 코어 4개(각 3.19GHz)
RAM	16GB
운영 체제	Windows Server 2008(64비트)
저장소	300GB 디스크 15개(각 15,000RPM)
네트워크 어댑터 수	2개
네트워크 어댑터 속도	초당 1기가비트
인증	Windows NTLM
소프트웨어 버전	Microsoft SQL Server 2008

테스트 결과 및 권장 사항

이 섹션에서는 테스트 결과에 대해 설명하고 다음 특성에 대한 권장 사항을 제공합니다.

• 데이터 특성

• 부하 특성

• 타이머 작업 성능

데이터 특성

용어 레이블 길이의 영향

먼저 용어 레이블 길이를 5자로 하여 기본 용어 저장소에 대해 테스트를 수행한 다음, 용어 레이블 길이를 250자로 변경하여 다시 테스트를 수행했습니다. 이 테스트에서는 대부분의 다른 테스트에 사용된 읽기 및 쓰기 작업 혼합에서보다 쓰기 작업의 비율이 월등히 높았습니다.

테스트	혼합 비율
용어 만들기	5%
추천 단어 가져오기	70%
일치 항목 가져오기	10%
페이징을 통해 용어 집합의 하위 용어 가져오기	5%
용어 유효성 검사	10%

아래 그래프에는 용어 집합 길이를 변경했을 때의 RPS(초당 요청 수) 결과가 나와 있습니다. 이 데이터를 통해, 용어 레이블 길이는 두 부하 모두에 대해 평균 RPS에 큰 영향을 주지 않음을 확인할 수 있습니다.

아래 그래프에는 CPU 및 메모리 사용이 나와 있습니다.

이 결과에서 알 수 있듯이, 용어 레이블 길이는 웹 서버 및 응용 프로그램의 CPU 및 메모리 사용에 큰 영향을 주지 않습니다. 그러나 용어 레이블 길이가 길어지면 데이터베이스 서버의 부하는 높아집니다.

결론 및 권장 사항: 용어 레이블 길이

용어 레이블 길이는 시스템 성능에 큰 영향을 주지 않습니다.

용어 저장소당 용어

기본 용어 저장소에 대해 테스트를 수행한 다음, 관리되는 용어 및 키워드의 수를 비례적으로 늘려 용어 저장소를 수직 확장했습니다(용어 1백만 개).

테스트를 위해 용어 저장소에서 키워드 용어 집합을 제거했을 때 아래의 두 그래프에 나와 있는 것처럼 용어가 10만 개, 50만 개, 1백만인 용어 집합의 성능 간에는 큰 차이가 없었습니다.

시스템에 지정된 테스트 부하를 적용했을 때, 키워드의 수를 1만 6천 개에서 80만 개로 늘리자 키워드를 만드는 데 소요되는 시간이 매우 길어졌습니다. 아래 그래프에서 이러한 추세를 확인할 수 있습니다.

결론 및 권장 사항: 용어 저장소당 용어

키워드를 만드는 사용자가 거의 없거나 키워드 수가 적으면 용어 저장소의 용어 수는 시스템 성능에 큰 영향을 주지 않습니다.

구조가 보다 복잡한 다른 용어 집합과는 달리, 키워드 용어 집합은 단순 목록에 저장됩니다. 단순 목록이 커질수록 이름이 같은 키워드가 이미 있는지를 확인하는 데 소요되는 시간이 길어집니다. 따라서 키워드 용어 집합이 큰 경우 키워드를 만드는 데 시간이 더 오래 걸립니다.

용어 저장소 관리자는 사용자가 키워드 용어를 만들 때의 대기 시간을 없애기 위해 키워드 용어 집합의 크기를 제한해야 합니다. 이렇게 하는 방법 중 하나는 키워드를 자주 일반 용어 집합으로 옮기는 것입니다. 그러면 용어 데이터를 보다 효율적으로 구성하고 성능을 높일 수 있습니다.

단순 목록의 용어 수가 15만 개보다 많은 용어 집합의 경우 대기 시간과 성능 문제가 발생할 수 있습니다. 단순 목록에 용어를 많이 포함하는 대신, 일반적으로 구조화된 용어 모음을 포함하는 관리되는 용어 집합을 사용할 수 있습니다. 용어 집합에 대한 자세한 내용은 관리되는 메타데이터 개요를 참조하십시오.

일반적인 오류

용어 저장소의 총 용어 수가 50만 개에 도달하면 사용자가 용어 저장소에 액세스할 때 여러 가지 예외가 발생할 수 있습니다. 팜 관리자는 관련 ULS(통합 로깅 서비스) 로그를 확인하여 예외를 찾아 해당 예외가 클라이언트 또는 서버에 적용되는지를 확인할 수 있습니다.

TimeoutException

TimeoutException 오류가 발생하는 경우 Managed Metadata Service의 client.config 파일 또는 web.config 파일에서 시간 제한 값을 수정할 수 있습니다. client.config 파일은 %PROGRAMFILES%\Microsoft Office Servers\14.0\WebClients\Metadata 폴더에 있고, web.config 파일은 %PROGRAMFILES%\Microsoft Office Servers\14.0\WebServices\Metadata 폴더에 있습니다. 다음의 4개 시간 제한 값이 있습니다.

• receiveTimeout: 받기 작업을 완료하도록 제공되는 시간 간격을 지정하는 시간 제한 값입니다.

• sendTimeout: 보내기 작업을 완료하도록 제공되는 시간 간격을 지정하는 시간 제한 값입니다.

• openTimeout: 열기 작업을 완료하도록 제공되는 시간 간격을 지정하는 시간 제한 값입니다.

• closeTimeout: 닫기 작업을 완료하도록 제공되는 시간 간격을 지정하는 시간 제한 값입니다.

이러한 시간 제한 값은 customBinding 섹션에서 정의됩니다. 시간이 초과되는 특정 작업을 기준으로 하여 시간 제한 값을 늘릴 수 있습니다. 예를 들어 메시지를 받을 때 시간이 초과되는 경우에는 ReceiveTimeout의 값만 늘리면 됩니다.

참고

HTTP와 HTTPS의 시간 제한 값은 서로 다르므로, HTTP 또는 HTTPS 중 하나에 대해 시간 제한 값을 수정해야 합니다.

시간 제한 값에 대한 자세한 내용은 <customBinding>(https://go.microsoft.com/fwlink/?linkid=214213&clcid=0x412)을 참조하십시오.

ThreadAbortException

ThreadAbortException 오류가 발생하는 경우에는 특정 웹 응용 프로그램의 web.config 파일에서 실행 시간 제한 값을 늘릴 수 있습니다. web.config 파일은 %inetpub%\wwwroot\wss\VirtualDirectories\<응용 프로그램 포트 번호> 폴더에 있습니다. 예를 들어 웹 응용 프로그램에서 TaxonomyInternalService를 요청하는 경우 먼저 웹 응용 프로그램의 web.config 파일을 확인한 다음 구성 노드에 아래 코드를 추가합니다.

  <location path="_vti_bin/TaxonomyInternalService.json">
    <system.web>
      <httpRuntime executionTimeout="3600" />
    </system.web>
  </location>

참고

기본 executionTimeout 값은 360초입니다.

용어 저장소당 용어 레이블

용어가 10만 개인 기본 용어 저장소에 대해 테스트를 수행했으며, 테스트 중에 아래 그래프와 같이 각 용어의 레이블 수를 늘렸습니다.

위의 그래프와 같이, 레이블 수가 증가해도 평균 RPS는 약간씩만 감소했습니다. 또한 아래 그래프와 같이 웹 서버, 응용 프로그램 서버 및 데이터베이스 서버의 CPU 및 메모리 사용도 약간씩만 증가했습니다.

결론 및 권장 사항: 용어 저장소당 용어 레이블

용어당 평균 레이블 수가 4개 미만이면 레이블 수는 시스템 성능에 큰 영향을 주지 않습니다.

요약: 데이터 특성

이 섹션에서는 용어 저장소 데이터의 서로 다른 세 특성(용어 레이블 길이, 용어 저장소당 용어 수, 용어 저장소당 용어 레이블 수)에 대한 테스트 결과를 검토합니다. 이 테스트를 통해 확인된 추세는 다음과 같습니다.

• 용어 레이블 길이를 250으로 늘려도 용어 저장소 성능에는 큰 영향을 주지 않습니다.

• 용어당 평균 레이블 수를 4개로 늘려도 용어 저장소 성능에는 큰 영향을 주지 않습니다.

• 용어 수를 1백만 개로 늘려도 용어 저장소 성능에는 큰 영향을 주지 않습니다.

• 단순 목록을 사용하는 용어 집합의 용어 저장소에 15만 개가 넘는 용어가 포함되어 있는 경우에는 용어 저장소에 새 용어를 추가하는 데 시간이 오래 걸릴 수 있습니다.

부하 특성

읽기/쓰기 혼합 변경의 영향

기본 읽기/쓰기 작업 테스트 혼합을 사용하여 테스트를 수행했으며, "분류 항목 만들기" 테스트를 변화하는 항목으로 지정했습니다. 아래 표에는 기준 테스트 혼합에서 사용된 특정 작업과 이러한 작업의 관련 비율이 나와 있습니다.

테스트	부하 비율
추천 단어 가져오기	73%
분류 항목 만들기	0%
일치 항목 가져오기	11%
용어 집합에서 페이징된 하위 용어 가져오기	5%
용어 유효성 검사	11%

테스트가 계속될 때마다 작성되는 용어 수가 증가했습니다. 아래 표에는 분당 작성된 평균 용어 수를 확인하여 평균 RPS를 구하는 방식으로 수행된 3회의 테스트 결과가 나와 있습니다.

분당 작성된 평균 용어 수	평균 RPS
0	182
8.4	157
20	139

아래 그래프에 나와 있는 것처럼, 분당 작성되는 평균 용어 수가 증가하면 RPS가 감소했습니다.

아래의 두 그래프에는 CPU 및 메모리 사용이 나와 있습니다.

결론 및 권장 사항: 읽기/쓰기 혼합 변경의 영향

쓰기 작업의 비율이 높아지면 성능 저장소의 성능은 저하된다고 할 수 있습니다. 쓰기 작업에서는 더 많은 데이터를 배타적으로 잠그기 때문에 읽기 작업 실행이 지연됩니다. 테스트 데이터에 따르면, 작성되는 평균 용어 수가 분당 20개에 도달할 때까지는 RPS가 크게 감소하지 않았습니다. 그러나 분당 평균 용어 작성 속도 20개는 매우 높은 값으로 일반적으로는 나타나지 않으며, 특히 완성된 용어 집합에서는 이러한 값이 나타나는 경우가 거의 없습니다. 용어 집합을 읽기 전용으로 만들면 쓰기 작업이 수행되지 않으므로 성능을 높일 수 있습니다.

용어 저장소 캐시

용어 저장소 캐시는 팜의 모든 웹 서버에 있으며 용어 집합 그룹, 용어 집합 및 용어를 포함할 수 있습니다. 테스트를 통해 용어 수가 증가하면 캐시 개체의 메모리 공간이 어떻게 바뀌는지를 확인했습니다. 용어 설명, 레이블 수, 사용자 지정 속성 등의 다른 요인도 캐시 크기에 영향을 줍니다. 테스트를 간소화하기 위해 기본 용어 저장소의 모든 용어에는 설명이나 사용자 지정 속성을 사용하지 않았으며, 길이가 250자인 레이블을 하나만 포함했습니다.

아래 그래프에서는 캐시의 용어 수 증가에 따른 메모리 공간 변화를 보여 줍니다.

결론 및 권장 사항: 용어 저장소 캐시

웹 서버의 메모리 사용은 캐시의 용어 수가 증가하면 그에 비례하여 증가합니다. 따라서 용어 수를 아는 경우 캐시 크기를 예측할 수 있습니다. 테스트 데이터에 따르면, 대부분의 시스템에서는 메모리 사용으로 인한 성능 문제가 발생하지 않습니다.

팜에서 사용하는 서비스 응용 프로그램

이 테스트에서는 데이터베이스가 같은 데이터베이스 서버에서 호스팅되는 Managed Metadata Service 응용 프로그램이 하나일 때와 두 개일 때의 성능 차이를 보여 줍니다.

아래 그래프에 나와 있는 것처럼, 부하가 동일할 때 서비스 응용 프로그램을 더 추가하면 RPS가 감소했습니다. 따라서 서비스 응용 프로그램을 더 추가하면 RPS가 감소한다고 할 수 있습니다.

서비스 응용 프로그램을 더 추가했을 때 대부분의 작업 대기 시간에는 큰 영향이 없었습니다. 그러나 다른 작업과는 달리, "추천 단어 가져오기" 작업은 사용 가능한 모든 서비스 응용 프로그램과 상호 작용하기 때문에 다음 그래프에 나와 있는 것처럼 서비스 응용 프로그램의 수가 증가하면 이 작업의 대기 시간이 길어졌습니다. 따라서 서비스 응용 프로그램 수가 증가하면 이 추세가 계속된다고 할 수 있습니다.

다음 그래프에 나와 있는 것처럼, 데이터베이스가 같은 서버에 있는 서비스 응용 프로그램이 두 개인 경우 데이터베이스 서버의 CPU 사용량은 크게 증가했으나 메모리 사용은 크게 증가하지 않았습니다.

결론 및 권장 사항: 팜에서 사용하는 서비스 응용 프로그램

둘 이상의 Managed Metadata Service 응용 프로그램을 유지 관리해야 하는 경우 키워드 추천 작업의 대기 시간을 적절한 수준으로 유지해야 합니다. 네트워크 대기 시간은 총 유효 대기 시간에도 영향을 줍니다. 따라서 Managed Metadata Service 응용 프로그램을 최대한 통합하는 것이 좋습니다.

SQL Server 컴퓨터 한 대에서 모든 서비스 응용 프로그램을 호스팅하는 경우에는 적절한 성능 목표를 지원할 수 있도록 서버의 CPU 및 메모리 리소스가 충분해야 합니다.

타이머 작업 성능

이 섹션에서는 Managed Metadata Service에서 수행되는 두 타이머 작업, 즉 콘텐츠 형식 구독자 타이머 작업 및 분류 업데이트 업데이트 스케줄러 타이머 작업)의 성능 특성을 보여 줍니다. 두 타이머 작업은 모두 지정된 웹 응용 프로그램에서 사이트 모음을 열거하며, 오랜 시간 동안 실행되어 대규모 팜의 경우 시스템 리소스를 많이 사용할 수 있습니다.

콘텐츠 형식 구독자 타이머 작업

콘텐츠 형식 구독자 타이머 작업은 게시된 콘텐츠 형식을 웹 응용 프로그램의 해당하는 모든 사이트 모음으로 배포합니다. 이 타이머 작업의 실행에 소요되는 총 시간은 배포해야 하는 콘텐츠 형식의 수, 콘텐츠 형식의 필드 수와 유형, 사이트 모음의 수 등 다양한 요인에 따라 달라집니다. 이 테스트에서는 다음과 같은 확장 요인이 전체 콘텐츠 형식 배포 시간에 주는 영향을 보여 줍니다.

• 웹 응용 프로그램의 사이트 모음 수

• 콘텐츠 형식의 수

첫 테스트에서는 콘텐츠 형식 10개를 게시한 다음 서로 다른 수의 사이트 모음에 배포했습니다. 아래 그래프에 나와 있는 것처럼, 콘텐츠 형식 배포 시간과 사이트 모음 수는 거의 비례했습니다.

이 테스트에서는 콘텐츠 형식 하나를 1,000개 사이트 모음에 게시한 다음 콘텐츠 형식 10개를 1,000개의 사이트 모음에 게시했습니다. 콘텐츠 형식 10개를 배포하는 시간은 1개를 배포하는 시간의 약 10배여서, 콘텐츠 형식 수와 배포 시간도 거의 비례 관계를 나타냈습니다.

결론 및 권장 사항: 콘텐츠 형식 구독자 타이머 작업

테스트 결과에 따르면, 콘텐츠 형식 하나를 사이트 모음 하나로 배포하는 데 걸리는 평균 시간은 거의 일정하게 유지되었습니다. 따라서 이 타이머 작업은 대규모 사이트 모음 집합에서 실행해도 안전합니다. 평균 배포 시간을 통해, 사이트 모음 수 및 배포할 콘텐츠 형식 수가 지정되어 있는 경우 타이머 작업 실행 시간을 예측할 수 있습니다. 실행 시간 값이 매우 큰 경우에는 타이머 작업을 실행하는 데 몇 시간, 심지어는 며칠이 걸릴 수도 있습니다. 그러나 이 타이머 작업은 일시 중지했다가 다시 시작할 수 있으며, 콘텐츠 작업 게시는 자주 수행하는 작업은 아닙니다.

타이머 작업 중에 콘텐츠 형식 푸시다운이 발생하면 이 타이머 작업을 실행하는 데 필요한 시간이 크게 길어질 수 있습니다(특히 목록이 많이 포함되는 경우). 콘텐츠 형식 푸시다운에 대한 자세한 내용은 Managed Metadata Service 응용 프로그램 정보에서 관리되는 메타데이터 연결 섹션을 참조하십시오.

팁

매우 큰 콘텐츠 형식을 게시할 때는 다음 오류가 표시될 수 있습니다.
WebException: 요청을 취소했습니다.
이 오류가 표시되는 이유는, 콘텐츠 형식 크기가 서비스 응용 프로그램의 기본 최대 HTTP 요청 크기인 4MB를 초과하기 때문입니다. 이 오류를 방지하려면 서비스 응용 프로그램의 web.config 파일에서 maximumRequestLength 값을 늘리면 됩니다.

분류 업데이트 스케줄러 타이머 작업

분류 업데이트 스케줄러 타이머 작업은 웹 응용 프로그램의 모든 사이트 모음에서 숨겨진 분류 목록을 용어 저장소와 동기화된 상태로 유지합니다. 이 타이머 작업을 실행하는 데 걸리는 총 시간은 업데이트해야 하는 항목의 수와 업데이트된 항목을 포함하는 사이트 모음의 수에 따라 달라집니다. 이 테스트에서는 웹 응용 프로그램의 사이트 모음 수와 숨겨진 목록 크기가 사이트 모음의 단일 항목을 업데이트하는 평균 시간에 주는 영향을 보여 줍니다.

아래 그래프에서는 사이트 모음 수와 한 사이트 모음의 용어 하나를 업데이트하는 데 걸리는 평균 시간 사이의 관계를 보여 줍니다.

아래 그래프에 나와 있는 것처럼, 숨겨진 목록 수가 증가하면 한 사이트 모음에서 용어 하나를 업데이트하는 데 걸리는 평균 시간이 길어집니다.

결론 및 권장 사항: 분류 업데이트 스케줄러 타이머 작업

사이트 모음 수가 증가해도 사이트 모음의 용어를 업데이트하는 데 걸리는 평균 시간에는 큰 영향을 주지 않습니다. 따라서 이 타이머 작업은 사이트 모음 수가 많은 웹 응용 프로그램에서 실행해도 안전합니다. 사이트 모음에서 용어를 업데이트하는 데 걸리는 평균 시간에 사이트 모음 수와 각 사이트 모음에서 업데이트되는 평균 용어 수를 곱하여 타이머 작업의 전체 실행 시간을 예측할 수 있습니다. 이 타이머 작업도 일시 중지했다가 다시 시작할 수 있습니다.

사이트 모음에서 사용하는 용어 수가 늘어남에 따라 분류 숨겨진 목록의 크기도 증가합니다. 따라서 숨겨진 목록이 커지면 타이머 작업 실행 시간이 길어질 수 있습니다.