IIS는 w3wp.exe 프로세스를 HTTP 요청이 없는 경우 기본적으로 20분이 지나면 자동적으로 프로세스를 종료시키도록 설정되어 있습니다.

이는, 서비스를 거의 사용하지 않는 경우, w3wp.exe를 내림으로써 개발자들이 설령 프로그램에 Memory Leak과 같은 버그를 남겨놨다고 해도 정상적으로 서비스가 될 수 있도록 만드는 장점을 갖습니다. 하지만 w3wp.exe가 내려간 상태에서 첫 번째 요청을 보내는 사용자는 로딩시간만큼 서비스 이용이 지연되는 문제가 발생하게 됩니다.

첫 번째 로딩시간을 단축하기 위해 아래 그림과 같이 IIS 응용프로그램 풀의 유휴 시간 제한 값을 기본 20분에서 ‘0’으로 조정하고 재 시작 시간 또한 ‘1,740분’에서 ‘0’으로 조정하는 방법을 통해, w3wp.exe를 내리지 않는 방법을 사용합니다(유휴 시간 제한 값은 표준 시간 간격 값보다 작거나 같아야 합니다).

< 유휴시간 제한 및 표준 시간 간격 >

그러나 이 방법은 프로그램 오류에 인한 문제 등으로 아예 응용프로그램 풀이 동작하지 않을 수도 있습니다. 특히, 한 개의 서버에 여러 개의 웹사이트를 운영할 경우, 여러 개의 응용프로그램 풀을 두게 되는데 이럴 경우, 설정 값을 ‘0’으로 할 경우, 웹사이트 프로그램 등에 문제가 있다면 응용프로그램 풀이 동작하지 않는 문제가 발생할 수 있습니다. 이러한 현상은 제 경우, 단일 응용프로그램 풀을 사용할 때보다 복수의 응용프로그램 풀을 사용할 때, 더 빈번하게 발생하는 것으로 나타났습니다.

IIS 최초 로딩속도도 빨라져야 하지만 응용프로그램이 중지되는 문제가 발생한다면 차라리 최초 로딩속도가 늦는게 차라리 더 나은 선택이 될 수도 있기 때문에 여러 개의 응용프로그램 풀 구성을 유지하면서도 최초 로딩속도를 줄일 수 잇는 방법에 초점을 두고 세팅작업을 지속중에 있습니다. 현재까지는 가능한 응용프로그램 풀의 유휴 시간 제한이나 표준 시간 간격 설정을 건드리지 않는게 좋을 것 같다는 판단이 들었습니다.

아래 그림은 '시작모드'를 재설정 하고 30분 뒤 측정한 결과입니다. 동일한 서버에서 운영되고 있는 웹사이트에 대한 측정결과 ‘시작모드’가 ‘OnDemand’으로 설정된 ‘cokonut.kr’ 사이트는 .505초로 나타난 반면, ‘AlwaysRunning’으로 설정된 ‘bwlab.kr’ 사이트의 접속 속도는 .39초로 나왔습니다. 다시 30분 뒤에 측정한 값은 cokonut.kr’ 사이트가 .432초, ‘bwlab.kr’ 사이트가 .301초로 ‘AlwaysRunning’의 효과가 있는 것으로 분석되었습니다.

< 시작모드 재설정 사이트와 기본 설정 사이트 속도 비교  >