눈으로 확인하는 maxWorkerThreads, minFreeThreads 설정값
이해를 돕기 위해, 우선 환경을 가정해 보겠습니다.
운영체제: 윈도우 서버 2003 32비트
CPU: 1개
.NET Framework: 2.0
위의 상태에서 posttest.aspx라는 파일의 내용을 다음과 같이 작성하고,
public partial class PostTest : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
string delay = HttpContext.Current.Request.Params["delay"];
if (string.IsNullOrEmpty(delay) == false)
{
int delaySecond = Int32.Parse(delay);
Thread.Sleep(delaySecond * 1000);
}
}
}
웹 부하 도구를 이용해서 "http://.../posttest.aspx?delay=120" 주소로 GET 요청을 보냅니다. 자, 그럼 결과가 어떻게 나올까요?
시각화를 멋지게 하기 위해서 "제니퍼 닷넷" 제품을 이용해서 보면, 아래 그림과 같이 동시 요청 12개에서 막혀 있는 것을 확인할 수 있습니다.
어떠세요? 의외의 결과인가요? 12개라니? 너무 적은 것 같습니다. 이상한 점이 하나 더 있습니다. 기본적으로, Windows Server 2003에서의 ASP.NET은 (20 * CPU 수)만큼의 동시 요청을 허용한다고 되어 있습니다. 분명히 20개라고 했는데 왜? 12개가 나오는 것일까요?
우선, "20"의 숫자가 나온 이유는 machine.config에서 지정되는 "processModel" 노드의 "maxWorkerThreads" 속성의 기본값이 20이기 때문입니다. 위의 테스트 환경에서는 CPU 수가 하나이기 때문에 20이지만, 최근의 쿼드 코어나 HT(Hyper Threading)까지 고려하여 8개의 논리 스레드 환경이라면 (20 * 8) = 160까지 늘어나게 됩니다.
20은 이제 그렇다 치고, 그럼 12개로 줄은 이유가 궁금해지는데요. 해답은 "httpRuntime" 노드의 "minFreeThreads" 속성의 기본값이 8이기 때문입니다. ASP.NET의 요청을 처리하는 스레드는 결국 닷넷에서 공통적으로 제공되는 ThreadPool을 그대로 재사용하고 있습니다. 이 때문에 ThreadPool.QueueUserWorkItem과 같은 메서드를 사용하는 경우에도 동일하게 ASP.NET의 요청 스레드가 점유됩니다. minFreeThreads 값은 바로 그런 별도의 스레드 풀 사용을 위해 남겨지는 값입니다.
정말 그런지 한번 볼까요? web.config(또는 machine.config)의 system.web / httpRuntime - minFreeThreads를 다음과 같이 바꿔서 다시 한번 테스트를 해봅니다.
=== web.config ===
<system.web>
<httpRuntime enable="True" minFreeThreads="0" minLocalRequestFreeThreads="0" />
...[생략]...
</system.web>
실제로 테스트 해보면, 위와 같이 변경했는데도 여전히 12에서 머무르는 것을 볼 수 있습니다. 왜냐하면, httpRuntime의 설정은 processModel이 설정되어야 하기 때문입니다.
=== machine.config ===
<system.web>
...[생략]...
<processModel enable="true" />
...[생략]...
</system.web>
자, 이제 다시 한번 시도하면, 다음과 같이 원하던 데로 20개의 동시 요청까지 허용되는 것을 확인할 수 있습니다.
minFreeThreads가 0이 되었으므로, 이 상태에서는 다음과 같이 posttest.aspx에 코드를 포함하고 있다면, Trace.WriteLine은 곧바로 실행되지 않습니다. 왜냐하면, ThreadPool에 허용된 20개의 스레드가 모두 aspx 처리로 인해 점유되어 있으므로 스케쥴링이 되지 않기 때문입니다. 따라서 Thread.Sleep에 지정된 시간이 지나고 나서야 정상적으로 Trace.WriteLine이 실행되어질 수 있습니다.
public partial class PostTest : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(
(object state) =>
{
System.Diagnostics.Trace.WriteLine(DateTime.Now);
}
));
string delay = HttpContext.Current.Request.Params["delay"];
if (string.IsNullOrEmpty(delay) == false)
{
int delaySecond = Int32.Parse(delay);
Thread.Sleep(delaySecond * 1000);
}
}
}
이제, 테스트를 위해 다시 httpRuntime 설정을 주석 처리하고, 12개의 동시 요청을 늘리기 위해 maxWorkerThreads 값을 100으로 변경해 볼까요?
=== machine.config ===
<system.web>
...[생략]...
<processModel enable="true" maxWorkerThreads="100" />
...[생략]...
</system.web>
확인을 해보면, (100 * 1) - 8 = 92개의 동시 요청이 허용됩니다.
동시 요청 12는 Long-running task가 많은 상황에서는 매우 작은 값입니다. 윈도우 서버 2003에서 ASP.NET을 운영 중이라면 자신의 서비스 상황에 맞게 maxWorkerThreads 값을 적절하게 조정해야 할 필요가 있어 보입니다. 주의해야 할 것은, CPU 수를 곱하기 때문에 만약 100으로 설정했다면, HT 가능한 Quad-Core 환경에서 최대 800개 까지 스레드가 생성될 수 있으므로 오히려 잘못 설정하면 스레드 문맥 전환에 따른 오버헤드가 더욱 클 수 있습니다.
참고로, 기억하실지 모르겠지만 윈도우 서버 2008의 경우에는 예전에 퀴즈 식으로 문제를 냈었답니다. ^^
성능 관리 퀴즈 두 번째 문제 (닷넷 개발자 컨퍼런스)
; https://www.sysnet.pe.kr/2/0/876
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]