답변:
예, 하루에 한 번 기본값으로 설정되는 이유는 웹 앱에 메모리 누수가있을 수 있다는 걱정이 없기 때문입니다. IIS 응용 프로그램 풀을 자주 재활용하는 데 따른 가장 큰 단점은 web.config 읽기, 어셈블리로드 및 asp.net 페이지의 재 컴파일 (및 사전 컴파일을 믿지 않는 경우)으로 인한 코드 비하를 초래한다는 것입니다. 이는 다소 무거운 프로세스이며 앱 풀이 재활용 된 후 다음 페이지 요청이 발생하여 특정 요청이 크게 느려질 때까지 발생하지 않습니다. IIS7에는 이제이 문제를 해결하기 위해 Application Warm Up 이라는 모듈을 다운로드 할 수 있습니다 .
개인적으로 재활용 일정을 세우는 대신 앱 시작 로그온과 함께 메모리 기반 최대 값을 사용하는 것을 선호합니다. 이를 통해 내 앱에 메모리 누수가 없다고 가정하고 앱 풀이 재활용 될 때 잘못 판명되었습니다.
1740 분은 29 시간입니다.
응용 프로그램 풀을 도입 한 버전 인 IIS 6을 개발할 때 응용 프로그램 풀이 자동으로 재활용 될 때 기본 시간 간격으로 기본값을 설정해야했습니다.
Wade는 24 시간 동안 가장 작은 소수이기 때문에 29 시간을 제안 했습니다 . 그는 하루에 한 번 이상 자주 발생하지 않는 반복적이고 반복되지 않는 패턴을 원했습니다. 웨이드의 말에 따르면 :“공명 패턴을 얻지 못했습니다”. 그 이후 기본값은 1740 분 (29 시간)입니다.
실제로 이것은 순수하게 유출 된 리소스를 정리하기위한 것입니다. 1740 분이 유일한 트리거 이벤트는 아닙니다. 특정 최대 요청 수 또는 특정 양의 작업자 프로세스 메모리를 초과 한 후에도 발생합니다. MSDN 라이브러리에 잘 설명되어 있습니다. 불행히도이 정책은 세션 상태 및 싱글 톤과 같은 정적과 같은 사항을 위반합니다. 앱은 사용자 경험을 방해하지 않도록 사용자를 다시 인증하거나 싱글 톤을 다시 초기화 할 수있을 정도로 강력해야합니다. ASP.NET 세션이 아닌 데이터베이스에서 인증 된 세션을 관리해야했습니다. 그렇지 않으면 이러한 트리거 중 하나로 서버가 재활용 될 때마다 사용자가 로그인 페이지로 다시 부팅되었습니다.