다음을 통해 공유

IIS 10.0 튜닝

IIS(Internet Information Services) 10.0은 Windows Server 2022에 포함되어 있습니다. IIS 8.5 및 IIS 7.0과 유사한 프로세스 모델을 사용합니다. 커널 모드 웹 드라이버(http.sys)는 HTTP 요청을 수신하고 라우팅하며 응답 캐시에서 요청을 충족합니다. 작업자 프로세스는 URL 하위 영역에 등록하고, http.sys 요청을 적절한 프로세스(또는 애플리케이션 풀에 대한 프로세스 집합)로 라우팅합니다.

HTTP.sys 연결 관리 및 요청 처리를 담당합니다. 요청은 HTTP.sys 캐시에서 제공되거나 추가 처리를 위해 작업자 프로세스에 전달될 수 있습니다. 여러 작업자 프로세스를 구성할 수 있으므로 비용을 절감하여 격리할 수 있습니다. 요청 처리의 작동 방식에 대한 자세한 내용은 다음 그림을 참조하세요.

iis 10.0의 요청 처리

HTTP.sys 응답 캐시를 포함합니다. 요청이 응답 캐시의 항목과 일치하면 HTTP.sys 커널 모드에서 직접 캐시 응답을 보냅니다. ASP.NET 같은 일부 웹 애플리케이션 플랫폼은 커널 모드 캐시에 동적 콘텐츠를 캐시할 수 있도록 하는 메커니즘을 제공합니다. IIS 10.0의 정적 파일 처리기는 http.sys 자주 요청되는 파일을 자동으로 캐시합니다.

웹 서버에 커널 모드 및 사용자 모드 구성 요소가 있으므로 최적의 성능을 위해 두 구성 요소를 모두 조정해야 합니다. 따라서 특정 워크로드에 대해 IIS 10.0 튜닝에는 다음 구성이 포함됩니다.

  • HTTP.sys 및 연결된 커널 모드 캐시

  • 작업자 프로세스 및 사용자 모드 IIS(애플리케이션 풀 구성 포함)

  • 성능에 영향을 주는 특정 튜닝 매개 변수

다음 섹션에서는 IIS 10.0의 커널 모드 및 사용자 모드 측면을 구성하는 방법에 대해 설명합니다.

커널 모드 설정

성능 관련 HTTP.sys 설정은 캐시 관리 및 연결 및 요청 관리라는 두 가지 광범위한 범주로 나 분류됩니다. 모든 레지스트리 설정은 다음 레지스트리 항목 아래에 저장됩니다.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters

참고 HTTP 서비스가 이미 실행 중인 경우 변경 내용을 적용하려면 HTTP 서비스를 다시 시작해야 합니다.

캐시 관리 설정

HTTP.sys 제공하는 한 가지 이점은 커널 모드 캐시입니다. 응답이 커널 모드 캐시에 있는 경우 커널 모드에서 HTTP 요청을 완전히 충족하여 요청을 처리하는 CPU 비용을 크게 낮출 수 있습니다. 그러나 IIS 10.0의 커널 모드 캐시는 실제 메모리를 기반으로 하며 항목의 비용은 해당 캐시가 차지하는 메모리입니다.

캐시의 항목은 사용되는 경우에만 유용합니다. 그러나 항목이 사용되는지 여부에 관계없이 항목은 항상 실제 메모리를 사용합니다. 사용 가능한 리소스(CPU 및 실제 메모리) 및 워크로드 요구 사항을 고려하여 캐시에 있는 항목의 유용성(캐시에서 처리할 수 있는 비용 절감) 및 항목 수명 동안의 비용(실제 메모리 사용)을 평가해야 합니다. HTTP.sys 캐시에서 유용하고 적극적으로 액세스된 항목만 유지하려고 하지만 특정 워크로드에 대한 HTTP.sys 캐시를 조정하여 웹 서버의 성능을 높일 수 있습니다.

다음은 HTTP.sys 커널 모드 캐시에 대한 몇 가지 유용한 설정입니다.

  • UriEnableCache 기본값: 1

    0이 아닌 값은 커널 모드 응답 및 조각 캐싱을 사용하도록 설정합니다. 대부분의 워크로드의 경우 캐시를 계속 사용하도록 설정해야 합니다. 매우 낮은 응답 및 조각 캐싱이 예상되는 경우 캐시를 사용하지 않도록 설정하는 것이 좋습니다.

  • UriMaxCacheMegabyteCount 기본값: 0

    커널 모드 캐시에 사용할 수 있는 최대 메모리를 지정하는 0이 아닌 값입니다. 기본값인 0을 사용하면 시스템에서 캐시에 사용할 수 있는 메모리 양을 자동으로 조정할 수 있습니다.

    참고 크기 집합을 최대값만 지정하면 시스템에서 캐시가 최대 집합 크기로 증가하지 않을 수 있습니다.

    Â

  • UriMaxUriBytes 기본값: 262144 바이트(256KB)

    커널 모드 캐시에 있는 항목의 최대 크기입니다. 이보다 큰 응답 또는 조각은 캐시되지 않습니다. 메모리가 충분한 경우 제한을 늘리는 것이 좋습니다. 메모리가 제한되고 큰 항목이 더 작은 항목으로 붐비는 경우 제한을 낮추는 것이 도움이 될 수 있습니다.

  • UriScavengerPeriod 기본값: 120초

    HTTP.sys 캐시는 청소기에 의해 주기적으로 검사되고 청소기 검사 간에 액세스되지 않는 항목이 제거됩니다. 청소기 기간을 높은 값으로 설정하면 청소기 검사 수가 줄어듭니다. 그러나 오래되고 자주 액세스하지 못하는 항목이 캐시에 남아 있을 수 있으므로 캐시 메모리 사용량이 증가할 수 있습니다. 기간을 너무 낮게 설정하면 청소기가 더 자주 검색되고 너무 많은 플러시 및 캐시 변동이 발생할 수 있습니다.

요청 및 연결 관리 설정

Windows Server 2022에서 HTTP.sys 자동으로 연결을 관리합니다. 다음 레지스트리 설정은 더 이상 사용되지 않습니다.

  • MaxConnections

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnections

  • IdleConnectionsHighMark

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMark

  • IdleConnectionsLowMark

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMark

  • IdleListTrimmerPeriod

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriod

  • RequestBufferLookasideDepth

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepth

  • InternalRequestLookasideDepth

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\InternalRequestLookasideDepth

사용자 모드 설정

이 섹션의 설정은 IISÂ 10.0 작업자 프로세스 동작에 영향을 줍니다. 이러한 설정의 대부분은 다음 XML 구성 파일에서 찾을 수 있습니다.

%SystemRoot%\system32\inetsrv\config\applicationHost.config

Appcmd.exe, IIS 10.0 관리 콘솔, WebAdministration 또는 IISAdministration PowerShell Cmdlet을 사용하여 변경합니다. 대부분의 설정은 자동으로 검색되며 IIS 10.0 작업자 프로세스 또는 웹 애플리케이션 서버를 다시 시작할 필요가 없습니다. applicationHost.config 파일에 대한 자세한 내용은 ApplicationHost.config 소개를 참조하세요.

NUMA 하드웨어에 이상적인 CPU 설정

Windows Server 2016부터 IIS 10.0은 NUMA 하드웨어의 성능과 확장성을 향상시키기 위해 스레드 풀 스레드에 대한 자동 이상적인 CPU 할당을 지원합니다. 이 기능은 기본적으로 사용하도록 설정되며 다음 레지스트리 키를 통해 구성할 수 있습니다.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu

이 기능을 사용하도록 설정하면 IIS 스레드 관리자는 현재 로드에 따라 모든 NUMA 노드의 모든 CPU에 IIS 스레드 풀 스레드를 균등하게 분산하기 위해 최선을 다하고 있습니다. 일반적으로 NUMA 하드웨어에 대해 이 기본 설정을 변경하지 않는 것이 좋습니다.

참고 이상적인 CPU 설정은 애플리케이션 풀의 CPU 설정에 도입된 작업자 프로세스 NUMA 노드 할당 설정(numaNodeAssignment 및 numaNodeAffinityMode)과 다릅니다. 이상적인 CPU 설정은 IIS가 스레드 풀 스레드를 배포하는 방식에 영향을 주지만 작업자 프로세스 NUMA 노드 할당 설정은 작업자 프로세스가 시작되는 NUMA 노드를 결정합니다.

사용자 모드 캐시 동작 설정

이 섹션에서는 IISÂ 10.0의 캐싱 동작에 영향을 주는 설정을 설명합니다. 사용자 모드 캐시는 통합 파이프라인에서 발생하는 전역 캐싱 이벤트를 수신 대기하는 모듈로 구현됩니다. 사용자 모드 캐시를 완전히 사용하지 않도록 설정하려면 applicationHost.config의 system.webServer/globalModules 구성 섹션에 설치된 모듈 목록에서 FileCacheModule(cachfile.dll) 모듈을 제거합니다.

system.webServer/caching

특성 설명 기본값
사용 False로 설정하면 사용자 모드 IIS 캐시를 사용하지 않도록 설정합니다. 캐시 적중률이 매우 작은 경우 캐시 코드 경로와 연결된 오버헤드를 방지하기 위해 캐시를 완전히 사용하지 않도록 설정할 수 있습니다. 사용자 모드 캐시를 사용하지 않도록 설정해도 커널 모드 캐시가 비활성화되지는 않습니다. True
enableKernelCache False로 설정하면 커널 모드 캐시를 사용하지 않도록 설정합니다. True
maxCacheSize IIS 사용자 모드 캐시 크기를 지정된 크기(메가바이트)로 제한합니다. IIS는 사용 가능한 메모리에 따라 기본값을 조정합니다. 자주 액세스하는 파일 집합의 크기와 RAM 또는 IIS 프로세스 주소 공간의 양에 따라 값을 신중하게 선택합니다. 0
maxResponseSize 지정된 크기까지 파일을 캐시합니다. 실제 값은 데이터 집합에서 가장 큰 파일의 수와 크기와 사용 가능한 RAM에 따라 달라집니다. 자주 요청되는 대용량 파일을 캐시하면 CPU 사용량, 디스크 액세스 및 관련 대기 시간을 줄일 수 있습니다. 262144

압축 동작 설정

7.0부터 시작하는 IIS는 기본적으로 정적 콘텐츠를 압축합니다. 또한 동적 콘텐츠 압축은 DynamicCompressionModule이 설치될 때 기본적으로 사용하도록 설정됩니다. 압축하면 대역폭 사용량이 줄어들지만 CPU 사용량이 증가합니다. 압축된 콘텐츠는 가능하면 커널 모드 캐시에 캐시됩니다. 8.5부터 IIS를 사용하면 정적 및 동적 콘텐츠에 대해 독립적으로 압축을 제어할 수 있습니다. 정적 콘텐츠는 일반적으로 GIF 또는 HTM 파일과 같이 변경되지 않는 콘텐츠를 나타냅니다. 동적 콘텐츠는 일반적으로 서버의 스크립트 또는 코드, 즉 ASP.NET 페이지에 의해 생성됩니다. 특정 확장의 분류를 정적 또는 동적으로 사용자 지정할 수 있습니다.

압축을 완전히 사용하지 않도록 설정하려면 applicationHost.config의 system.webServer/globalModules 섹션에 있는 모듈 목록에서 StaticCompressionModule 및 DynamicCompressionModule을 제거합니다.

system.webServer/httpCompression

특성 설명 기본값
staticCompression-EnableCpuUsage

staticCompression-DisableCpuUsage

dynamicCompression-EnableCpuUsage

dynamicCompression-DisableCpuUsage		 현재 백분율 CPU 사용량이 지정된 제한을 초과하거나 초과하는 경우 압축을 사용하거나 사용하지 않도록 설정합니다.

IIS 7.0부터 안정 상태 CPU가 사용 안 함 임계값 이상으로 증가하면 압축이 자동으로 비활성화됩니다. CPU가 사용 임계값 아래로 떨어지면 압축이 활성화됩니다.		 각각, 50, 100, 50, 90
directory 압축된 버전의 정적 파일이 일시적으로 저장되고 캐시되는 디렉터리를 지정합니다. 자주 액세스하는 경우 시스템 드라이브에서 이 디렉터리를 이동하는 것이 좋습니다. %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files
doDiskSpaceLimiting 압축된 모든 파일이 차지할 수 있는 디스크 공간의 한도가 있는지 여부를 지정합니다. 압축 파일은 디렉터리 특성에 의해 지정된 압축 디렉터리에 저장됩니다. True
maxDiskSpaceUsage 압축된 파일이 압축 디렉터리에서 차지할 수 있는 디스크 공간의 바이트 수를 지정합니다.

압축된 모든 콘텐츠의 총 크기가 너무 크면 이 설정을 늘려야 할 수 있습니다.		 100MB

system.webServer/urlCompression

특성 설명 기본값
doStaticCompression 정적 콘텐츠가 압축되는지 여부를 지정합니다. True
doDynamicCompression 동적 콘텐츠가 압축되는지 여부를 지정합니다. True

참고 항목

평균 CPU 사용량이 낮은 IIS 10.0을 실행하는 서버의 경우 특히 응답이 큰 경우 동적 콘텐츠에 압축을 사용하도록 설정하는 것이 좋습니다. 이 작업은 먼저 테스트 환경에서 수행하여 기준에서 CPU 사용량에 미치는 영향을 평가해야 합니다.

기본 문서 목록 튜닝

기본 문서 모듈은 디렉터리의 루트에 대한 HTTP 요청을 처리하고 Default.htm 또는 Index.htm 같은 특정 파일에 대한 요청으로 변환합니다. 평균적으로 인터넷의 모든 요청 중 약 25%가 기본 문서 경로를 통과합니다. 이는 개별 사이트에 따라 크게 다릅니다. HTTP 요청이 파일 이름을 지정하지 않으면 기본 문서 모듈은 파일 시스템의 각 이름에 대해 허용되는 기본 문서 목록을 검색합니다. 특히 콘텐츠에 도달하려면 네트워크 왕복을 수행하거나 디스크를 터치해야 하는 경우 성능에 부정적인 영향을 줄 수 있습니다.

기본 문서를 선택적으로 사용하지 않도록 설정하거나 문서 목록을 줄이거나 정렬하여 오버헤드를 방지할 수 있습니다. 기본 문서를 사용하는 웹 사이트의 경우 목록을 사용하는 기본 문서 유형으로만 줄여야 합니다. 또한 가장 자주 액세스하는 기본 문서 파일 이름으로 시작하도록 목록을 정렬합니다.

applicationHost.config의 위치 태그 내에서 구성을 사용자 지정하거나 콘텐츠 디렉터리에 직접 web.config 파일을 삽입하여 특정 URL에서 기본 문서 동작을 선택적으로 설정할 수 있습니다. 이렇게 하면 필요한 경우에만 기본 문서를 사용하도록 설정하고 목록을 각 URL에 대한 올바른 파일 이름으로 설정하는 하이브리드 접근 방식을 사용할 수 있습니다.

기본 문서를 완전히 사용하지 않도록 설정하려면 applicationHost.config의 system.webServer/globalModules 섹션에 있는 모듈 목록에서 DefaultDocumentModule을 제거합니다.

system.webServer/defaultDocument

특성 설명 기본값
사용 기본 문서를 사용하도록 지정합니다. True
<files> 요소 기본 문서로 구성된 파일 이름을 지정합니다. 기본 목록은 Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm 및 Default.aspx입니다.

중앙 이진 로깅

서버 세션에 수많은 URL 그룹이 있는 경우 개별 URL 그룹에 대해 수백 개의 형식이 지정된 로그 파일을 만들고 디스크에 로그 데이터를 쓰는 프로세스는 중요한 CPU 및 메모리 리소스를 빠르게 소비하여 성능 및 확장성 문제를 생성할 수 있습니다. 중앙 집중식 이진 로깅은 로깅에 사용되는 시스템 리소스의 양을 최소화하는 동시에 필요한 조직에 대한 자세한 로그 데이터를 제공합니다. 이진 형식 로그를 구문 분석하려면 사후 처리 도구가 필요합니다.

centralLogFileMode 특성을 CentralBinary로 설정하고 사용 특성을 True로 설정하여 중앙 이진 로깅을 사용하도록 설정할 수 있습니다. 시스템 활동과 로깅 작업 간의 경합을 방지하려면 중앙 로그 파일의 위치를 시스템 파티션에서 전용 로깅 드라이브로 이동하는 것이 좋습니다.

system.applicationHost/log

특성 설명 기본값
centralLogFileMode 서버의 로깅 모드를 지정합니다. 중앙 이진 로깅을 사용하도록 설정하려면 이 값을 CentralBinary로 변경합니다. 사이트

system.applicationHost/log/centralBinaryLogFile

특성 설명 기본값
사용 중앙 이진 로깅을 사용할지 여부를 지정합니다. False
directory 로그 항목이 기록되는 디렉터리를 지정합니다. %SystemDrive%\inetpub\logs\LogFiles

애플리케이션 및 사이트 튜닝

다음 설정은 애플리케이션 풀 및 사이트 튜닝과 관련이 있습니다.

system.applicationHost/applicationPools/applicationPoolDefaults

특성 설명 기본값
queueLength 이후 요청이 거부되기 전에 애플리케이션 풀에 대해 대기 중인 요청 수를 HTTP.sys에 나타냅니다. 이 속성의 값을 초과하면 IIS는 503 오류가 있는 후속 요청을 거부합니다.

503 오류가 관찰되는 경우 대기 시간이 긴 백 엔드 데이터 저장소와 통신하는 애플리케이션에 대해 이를 늘리는 것이 좋습니다.		 1000
enable32BitAppOnWin64 True이면 64비트 프로세서가 있는 컴퓨터에서 32비트 애플리케이션을 실행할 수 있습니다.

메모리 사용이 중요한 경우 32비트 모드를 사용하도록 설정하는 것이 좋습니다. 포인터 크기와 명령 크기는 더 작기 때문에 32비트 애플리케이션은 64비트 애플리케이션보다 적은 메모리를 사용합니다. 64비트 컴퓨터에서 32비트 애플리케이션을 실행하는 단점은 사용자 모드 주소 공간이 4GB로 제한된다는 것입니다.		 False

system.applicationHost/sites/VirtualDirectoryDefault

특성 설명 기본값
allowSubDirConfig IIS가 현재 수준(True)보다 낮은 콘텐츠 디렉터리에서 web.config 파일을 찾거나 현재 수준(False)보다 낮은 콘텐츠 디렉터리에서 web.config 파일을 찾을지 여부를 지정합니다. 가상 디렉터리에서만 구성을 허용하는 간단한 제한을 적용하면 IISÂ 10.0은 /<name>.htm이 가상 디렉터리가 아닌 한 구성 파일을 찾을 수 없다는 것을 알 수 있습니다. 추가 파일 작업을 건너뛰면 임의로 액세스하는 정적 콘텐츠 집합이 매우 큰 웹 사이트의 성능이 크게 향상될 수 있습니다. True

IIS 10.0 모듈 관리

IIS 10.0은 모듈 구조체를 지원하기 위해 사용자가 확장할 수 있는 여러 모듈로 고려되었습니다. 이 소인수분해는 비용이 적습니다. 각 모듈에 대해 통합 파이프라인은 모듈과 관련된 모든 이벤트에 대해 모듈을 호출해야 합니다. 이는 모듈이 작업을 수행해야 하는지 여부에 관계없이 발생합니다. 특정 웹 사이트와 관련이 없는 모든 모듈을 제거하여 CPU 주기 및 메모리를 절약할 수 있습니다.

간단한 정적 파일을 위해 조정된 웹 서버에는 UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule 및 HttpLoggingModule의 5개 모듈만 포함될 수 있습니다.

applicationHost.config에서 모듈을 제거하려면 system.webServer/globalModules에서 모듈 선언을 제거하는 것 외에도 system.webServer/handlers 및 system.webServer/modules 섹션에서 모듈에 대한 모든 참조를 제거합니다.

클래식 ASP 설정

클래식 ASP 요청을 처리하는 주요 비용에는 스크립트 엔진 초기화, 요청된 ASP 스크립트를 ASP 템플릿으로 컴파일, 스크립트 엔진에서 템플릿 실행 등이 포함됩니다. 템플릿 실행 비용은 요청된 ASP 스크립트의 복잡성에 따라 달라지지만 IIS 클래식 ASP 모듈은 메모리 및 디스크(메모리 내 템플릿 캐시 오버플로인 경우에만)의 메모리 및 캐시 템플릿에 스크립트 엔진을 캐시하여 CPU 바인딩 시나리오에서 성능을 높일 수 있습니다.

다음 설정은 클래식 ASP 템플릿 캐시 및 스크립트 엔진 캐시를 구성하는 데 사용되며 ASP.NET 설정에 영향을 미치지 않습니다.

system.webServer/asp/cache

특성 설명 기본값
diskTemplateCacheDirectory 메모리 내 캐시가 오버플로될 때 ASP가 컴파일된 템플릿을 저장하는 데 사용하는 디렉터리의 이름입니다.

권장 사항: 많이 사용되지 않는 디렉터리(예: 운영 체제, IIS 로그 또는 자주 액세스하는 기타 콘텐츠와 공유되지 않는 드라이브)로 설정합니다.		 %SystemDrive%\inetpub\temp\ASP Compiled Templates
maxDiskTemplateCacheFiles 디스크에 캐시할 수 있는 컴파일된 ASP 템플릿의 최대 수를 지정합니다.

권장 사항: 0x7FFFFFFF 최대값으로 설정합니다.		 2000
scriptFileCacheSize 이 특성은 메모리에 캐시할 수 있는 컴파일된 ASP 템플릿의 최대 수를 지정합니다.

권장 사항: 애플리케이션 풀에서 제공하는 자주 요청되는 ASP 스크립트 수 이상으로 설정합니다. 가능하면 메모리 제한에 허용되는 만큼의 ASP 템플릿으로 설정합니다.		 500
scriptEngineCacheMax 메모리에 캐시된 상태로 유지할 최대 스크립트 엔진 수를 지정합니다.

권장 사항: 애플리케이션 풀에서 제공하는 자주 요청되는 ASP 스크립트 수 이상으로 설정합니다. 가능하면 메모리 제한에서 허용하는 만큼의 스크립트 엔진으로 설정합니다.		 250

system.webServer/asp/limits

특성 설명 기본값
processorThreadMax ASP에서 만들 수 있는 프로세서당 최대 작업자 스레드 수를 지정합니다. 현재 설정이 부하를 처리할 수 없는 경우 증가합니다. 이로 인해 요청을 처리할 때 오류가 발생하거나 CPU 리소스의 사용량이 부족해질 수 있습니다. 25

system.webServer/asp/comPlus

특성 설명 기본값
executeInMta IIS가 ASP 콘텐츠를 제공하는 동안 오류 또는 오류가 감지되면 True로 설정합니다. 예를 들어 각 사이트가 자체 작업자 프로세스에서 실행되는 여러 격리된 사이트를 호스팅할 때 발생할 수 있습니다. 오류는 일반적으로 이벤트 뷰어 COM+에서 보고됩니다. 이 설정을 사용하면 ASP에서 다중 스레드 아파트 모델을 사용할 수 있습니다. False

ASP.NET 동시성 설정

ASP.NET 3.5

기본적으로 ASP.NET 서버의 안정적인 상태 메모리 사용량을 줄이기 위해 요청 동시성을 제한합니다. 높은 동시성 애플리케이션은 전반적인 성능을 향상시키기 위해 일부 설정을 조정해야 할 수 있습니다. aspnet.config 파일에서 이 설정을 변경할 수 있습니다.

<system.web>
  <applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>

다음 설정은 시스템에서 리소스를 완전히 사용하는 데 유용합니다.

  • maxConcurrentRequestPerCpu 기본값: 5000

    이 설정은 시스템에서 ASP.NET 요청을 동시에 실행하는 최대 수를 제한합니다. 기본값은 ASP.NET 애플리케이션의 메모리 소비를 줄이기 위해 보수적입니다. 긴 동기 I/O 작업을 수행하는 애플리케이션을 실행하는 시스템에서 이 제한을 늘리는 것이 좋습니다. 그렇지 않으면 기본 설정을 사용할 때 높은 부하에서 큐 제한을 초과하여 큐 또는 요청 실패로 인해 대기 시간이 높아질 수 있습니다.

ASP.NET 4.6

maxConcurrentRequestPerCpu 설정 외에도 ASP.NET 4.7은 비동기 작업에 크게 의존하는 애플리케이션의 성능을 향상시키는 설정을 제공합니다. aspnet.config 파일에서 설정을 변경할 수 있습니다.

<system.web>
  <applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>
  • percentCpuLimit 기본값: 90 비동기 요청에는 이러한 시나리오에서 엄청난 부하(하드웨어 기능 초과)가 발생할 때 몇 가지 확장성 문제가 있습니다. 문제는 비동기 시나리오에 대한 할당 특성 때문입니다. 이러한 조건에서 할당은 비동기 작업이 시작될 때 발생하며 완료되면 사용됩니다. 그 때까지는 개체가 GC에 의해 1세대 또는 2세대로 이동되었을 수 있습니다. 이 경우 로드를 늘리면 지점까지 초당 요청 수(rps)가 증가합니다. 이 시점을 통과하면 GC에서 소요된 시간이 문제가 되기 시작하고 rps가 급락하기 시작하여 배율 조정 효과가 저하됩니다. 이 문제를 해결하기 위해 cpu 사용량이 percentCpuLimit 설정을 초과하면 요청이 ASP.NET 네이티브 큐로 전송됩니다.
  • percentCpuLimitMinActiveRequestPerCpu 기본값: 100 CPU 제한(percentCpuLimit 설정)은 요청 수를 기반으로 하는 것이 아니라 비용이 많이 듭니다. 따라서 CPU를 많이 사용하는 요청이 몇 번만 있을 수 있으므로 들어오는 요청 외에는 비울 방법이 없는 네이티브 큐의 백업이 발생할 수 있습니다. 이 문제를 해결하기 위해 percentCpuLimitMinActiveRequestPerCpu를 사용하여 제한이 시작되기 전에 최소 요청 수가 처리되는지 확인할 수 있습니다.

작업자 프로세스 및 재활용 옵션

IIS 작업자 프로세스를 재활용하기 위한 옵션을 구성하고 서비스 또는 컴퓨터를 다시 설정하거나 개입하지 않고도 심각한 상황이나 이벤트에 대한 실질적인 솔루션을 제공할 수 있습니다. 이러한 상황 및 이벤트에는 메모리 누수, 메모리 부하 증가 또는 응답하지 않거나 유휴 작업자 프로세스가 포함됩니다. 일반적인 조건에서는 재활용 옵션이 필요하지 않을 수 있으며 재활용을 해제하거나 매우 드물게 재활용하도록 시스템을 구성할 수 있습니다.

recycling/periodicRestart 요소에 특성을 추가하여 특정 애플리케이션에 대한 프로세스 재활용을 사용하도록 설정할 수 있습니다. 메모리 사용량, 고정된 요청 수 및 고정 기간을 비롯한 여러 이벤트에 의해 재활용 이벤트를 트리거할 수 있습니다. 작업자 프로세스가 재활용되면 대기 중인 요청과 실행 요청이 드레이닝되고 새 프로세스가 동시에 새 요청을 처리하기 시작합니다. recycling/periodicRestart 요소는 애플리케이션별 요소입니다. 즉, 다음 표의 각 특성은 애플리케이션별로 분할됩니다.

system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart

특성 설명 기본값
메모리 가상 메모리 사용량이 지정된 한도(킬로바이트)를 초과하는 경우 프로세스 재활용을 사용하도록 설정합니다. 작은 2GB 주소 공간이 있는 32비트 컴퓨터에 유용한 설정입니다. 메모리 부족 오류로 인해 실패한 요청을 방지하는 데 도움이 될 수 있습니다. 0
privateMemory 프라이빗 메모리 할당이 지정된 한도(킬로바이트)를 초과하는 경우 프로세스 재활용을 사용하도록 설정합니다. 0
requests 특정 수의 요청 후에 프로세스 재활용을 사용하도록 설정합니다. 0
time 지정된 기간 후에 프로세스 재활용을 사용하도록 설정합니다. 29:00:00

동적 작업자 프로세스 페이지 아웃 튜닝

Windows Server 2012 R2부터 IIS는 잠시 유휴 상태인 후 일시 중단하도록 작업자 프로세스를 구성하는 옵션을 제공합니다(IIS 7 이후 존재했던 종료 옵션 외).

유휴 작업자 프로세스 페이지 아웃 및 유휴 작업자 프로세스 종료 기능 둘 다의 주요 목적은 서버에서 메모리 사용률을 절약하는 것입니다. 사이트는 단지 거기에 앉아 있어도 많은 메모리를 사용할 수 있기 때문에 수신 대기합니다. 사이트에 사용되는 기술(정적 콘텐츠 및 ASP.NET 및 기타 프레임워크)에 따라 사용되는 메모리는 약 10MB에서 수백 MB까지일 수 있으며, 이는 서버가 여러 사이트로 구성된 경우 사이트에 대한 가장 효과적인 설정을 파악하면 활성 및 일시 중단된 사이트의 성능을 크게 향상시킬 수 있음을 의미합니다.

세부 정보로 진행하기 전에 메모리 제약 조건이 없는 경우 사이트를 일시 중단하거나 종료하지 않도록 설정하는 것이 가장 좋습니다. 결국, 컴퓨터에서 유일한 작업자 프로세스인 경우 작업자 프로세스를 종료하는 데는 거의 가치가 없습니다.

참고 항목

사이트에서 메모리 누수 또는 불안정한 코드와 같은 불안정한 코드를 실행하는 경우 유휴 상태에서 사이트를 종료하도록 설정하는 것이 코드 버그를 수정하는 빠르고 더티 대안이 될 수 있습니다. 이는 권장되는 것이 아니지만, 더 영구적인 솔루션이 작동하는 동안 이 기능을 정리 메커니즘으로 사용하는 것이 더 좋을 수 있습니다.]

고려해야 할 또 다른 요인은 사이트가 많은 메모리를 사용하는 경우 컴퓨터가 작업자 프로세스에서 사용하는 데이터를 디스크에 기록해야 하기 때문에 일시 중단 프로세스 자체가 큰 타격을 받습니다. 작업자 프로세스가 큰 메모리 청크를 사용하는 경우 일시 중단하는 것이 다시 시작될 때까지 기다려야 하는 비용보다 더 비쌀 수 있습니다.

작업자 프로세스 일시 중단 기능을 최대한 활용하려면 각 애플리케이션 풀에서 사이트를 검토하고 일시 중단해야 하는 사이트, 종료해야 하는 사이트 및 무기한 활성화해야 하는 항목을 결정해야 합니다. 각 작업 및 각 사이트에 대해 이상적인 시간 제한 기간을 파악해야 합니다.

이상적으로, 일시 중단 또는 종료를 위해 구성할 사이트는 매일 방문자가 있지만 항상 활성 상태로 유지하는 것으로는 충분하지 않습니다. 일반적으로 하루에 약 20명의 고유 방문자가 있는 사이트입니다. 사이트의 로그 파일을 사용하여 트래픽 패턴을 분석하고 평균 일일 트래픽을 계산할 수 있습니다.

특정 사용자가 사이트에 연결되면 일반적으로 잠시 동안 유지되어 추가 요청을 수행하므로 일일 요청을 계산하는 것만으로는 실제 트래픽 패턴을 정확하게 반영하지 못할 수 있습니다. 보다 정확한 읽기를 위해 Microsoft Excel과 같은 도구를 사용하여 요청 간의 평균 시간을 계산할 수도 있습니다. 예시:

숫자 요청 URL 요청 시간 델타
1 /SourceSilverLight/Geosource.web/grosource.html 1,001
2 /SourceSilverLight/Geosource.web/sliverlight.js 1.0.1.0 0:09
3 /SourceSilverLight/Geosource.web/clientbin/geo/1.aspx 10:11 0:01
4 /lClientAccessPolicy.xml 1,012 0:01
5 / SourceSilverLight/GeosourcewebService/Service.asmx 1,023 0:11
6 / SourceSilverLight/Geosource.web/GeoSearchServer...¦. 1,150 1:27
7 /rest/Services/CachedServices/Silverlight_load_la...¦ 1,250 1:00
8 /rest/Services/CachedServices/Silverlight_basemap...¦. 12:51 0:01
9 /rest/Services/DynamicService/ Silverlight_basemap...¦. 1,259 0:08
10 /rest/Services/CachedServices/Ortho_2004_cache.as... 1,340 0:41
11 /rest/Services/CachedServices/Ortho_2005_cache.js 1,340 0:00
12 /rest/Services/CachedServices/OrthoBaseEngine.aspx 13:41 0:01

하지만 어려운 부분은 어떤 설정을 적용할지 파악하는 것입니다. 이 경우 사이트는 사용자로부터 많은 요청을 받으며, 위의 표에서는 4시간 동안 총 4개의 고유한 세션이 발생했음을 보여 줍니다. 애플리케이션 풀의 작업자 프로세스 일시 중단에 대한 기본 설정을 사용하면 기본 시간 제한 20분 후에 사이트가 종료됩니다. 즉, 이러한 각 사용자가 사이트 스핀업 주기를 경험하게 됩니다. 대부분의 경우 사이트가 유휴 상태이므로 일시 중단하면 리소스가 절약되고 사용자가 거의 즉시 사이트에 도달할 수 있기 때문에 작업자 프로세스 일시 중단에 이상적인 후보입니다.

이에 대한 최종적이고 매우 중요한 점은 디스크 성능이 이 기능에 매우 중요하다는 것입니다. 일시 중단 및 절전 모드 해제 프로세스에는 하드 드라이브에 대량의 데이터를 쓰고 읽는 작업이 포함되므로 이를 위해 빠른 디스크를 사용하는 것이 좋습니다. SSD(Solid State Drives)가 이상적이고 권장되며 Windows 페이지 파일이 이 파일에 저장되어 있는지 확인해야 합니다(운영 체제 자체가 SSD에 설치되지 않은 경우 페이지 파일을 이동하도록 운영 체제를 구성).

SSD 사용 여부에 관계없이 파일 크기 조정 없이 페이지 아웃 데이터를 쓰기 위해 페이지 파일의 크기를 수정하는 것이 좋습니다. 기본적으로 Windows는 필요에 따라 크기를 자동으로 조정하도록 구성되므로 운영 체제에서 페이지 파일에 데이터를 저장해야 하는 경우 페이지 파일 크기 조정이 발생할 수 있습니다. 크기를 고정 크기로 설정하면 크기 조정을 방지하고 성능을 많이 향상시킬 수 있습니다.

미리 고정된 페이지 파일 크기를 구성하려면 일시 중단할 사이트 수와 사용 중인 메모리 양에 따라 이상적인 크기를 계산해야 합니다. 활성 작업자 프로세스의 평균이 200MB이고 일시 중단될 서버에 500개의 사이트가 있는 경우 페이지 파일은 페이지 파일의 기본 크기보다 최소(200 * 500)MB 이상이어야 합니다(이 예제에서는 base + 100GB).

참고 항목

사이트가 일시 중단되면 각각 약 6MB를 사용하므로 이 경우 모든 사이트가 일시 중단된 경우 메모리 사용량은 약 3GB가 됩니다. 하지만 실제로는 모든 계정을 동시에 정지시킬 수는 없을 것입니다.

전송 계층 보안 튜닝 매개 변수

TLS(Transport Layer Security)를 사용하면 추가 CPU 비용이 부과됩니다. TLS의 가장 비싼 구성 요소는 전체 핸드셰이크를 포함하기 때문에 세션 설립을 설정하는 비용입니다. 다시 연결, 암호화 및 암호 해독도 비용에 추가됩니다. TLS 성능을 향상시키려면 다음을 수행합니다.

  • TLS 세션에 대해 HTTP 연결 유지를 사용하도록 설정합니다. 이렇게 하면 세션 설정 비용이 제거됩니다.

  • 적절한 경우, 특히 비 연동 트래픽에서 세션을 다시 사용합니다.

  • 암호화가 필요한 사이트 또는 전체 사이트에만 암호화를 선택적으로 적용합니다.

참고 항목

  • 키가 클수록 보안이 강화되지만 CPU 시간도 더 많이 사용됩니다.
  • 모든 구성 요소를 암호화할 필요가 없습니다. 그러나 일반 HTTP와 HTTPS를 혼합하면 페이지의 모든 콘텐츠가 안전하지 않다는 팝업 경고가 발생할 수 있습니다.

ISAPI(Internet Server Application Programming Interface)

ISAPI 애플리케이션에는 특별한 튜닝 매개 변수가 필요하지 않습니다. 프라이빗 ISAPI 확장을 작성하는 경우 성능 및 리소스 사용을 위해 작성되었는지 확인합니다.

관리 코드 튜닝 지침

IIS 10.0의 통합 파이프라인 모델을 사용하면 높은 수준의 유연성과 확장성을 사용할 수 있습니다. 네이티브 또는 관리 코드로 구현되는 사용자 지정 모듈을 파이프라인에 삽입하거나 기존 모듈을 대체할 수 있습니다. 이 확장성 모델은 편의성과 단순성을 제공하지만 전역 이벤트에 연결하는 새 관리형 모듈을 삽입하기 전에 주의해야 합니다. 전역 관리 모듈을 추가하면 정적 파일 요청을 비롯한 모든 요청이 관리 코드를 터치해야 합니다. 사용자 지정 모듈은 가비지 수집과 같은 이벤트에 취약합니다. 또한 사용자 지정 모듈은 네이티브 코드와 관리 코드 간의 데이터 마샬링으로 인해 상당한 CPU 비용을 추가합니다. 가능하면 관리되는 모듈에 대해 preCondition을 managedHandler로 설정해야 합니다.

콜드 시작 성능을 향상시키려면 ASP.NET 웹 사이트를 미리 컴파일하거나 IIS 애플리케이션 초기화 기능을 활용하여 애플리케이션을 준비해야 합니다.

세션 상태가 필요하지 않은 경우 각 페이지에 대해 세션 상태를 해제해야 합니다.

I/O 바인딩된 작업이 많은 경우 비동기 버전의 관련 API를 사용하여 훨씬 더 나은 확장성을 제공합니다.

또한 출력 캐시를 올바르게 사용하면 웹 사이트의 성능도 향상됩니다.

격리 모드(사이트당 하나의 애플리케이션 풀)에서 ASP.NET 스크립트를 포함하는 여러 호스트를 실행하는 경우 메모리 사용량을 모니터링합니다. 동시에 실행되는 애플리케이션 풀의 예상 수에 충분한 RAM이 서버에 있는지 확인합니다. 여러 격리된 프로세스 대신 여러 애플리케이션 도메인을 사용하는 것이 좋습니다.

IIS 성능에 영향을 주는 기타 문제

다음 문제는 IIS 성능에 영향을 줄 수 있습니다.

  • 캐시를 인식하지 않는 필터 설치

    HTTP 캐시 인식이 아닌 필터를 설치하면 IIS에서 캐싱을 완전히 사용하지 않도록 설정하여 성능이 저하됩니다. IISÂ 6.0 이전에 작성된 ISAPI 필터로 인해 이 동작이 발생할 수 있습니다.

  • CGI(Common Gateway Interface) 요청

    성능상의 이유로 CGI 애플리케이션을 사용하여 요청을 처리하는 것은 IIS에서 권장되지 않습니다. CGI 프로세스를 자주 만들고 삭제하려면 상당한 오버헤드가 수반됩니다. 더 나은 대안으로는 FastCGI, ISAPI 애플리케이션 스크립트 및 ASP 또는 ASP.NET 스크립트를 사용하는 것이 포함됩니다. 이러한 각 옵션에 대해 격리를 사용할 수 있습니다.

추가 참조