Server.CreateObject 구문을 단속하지 않으면 대용량 시스템에 문제가 많다는 사실은 오래 전부터 있어 온 이야기이다. 그러나, 실제 저 문제에 의해 죽는 시스템은 생각보다 많지 않다.

웹 사이트 성능을 측정하면서 많은 부분 간과하는 것이 바로 CPU와 메모리에 지나칠 정도로 집착하는 것이다. 실제로 죽는 웹 서버는 메모리 소요량이 많아서도 아니며, CPU 점유율이 많아서도 아니다. 간혹 CPU 점유율이 많은 서버가 존재할 수는 있겠지만, 이는 데이터베이스 등에서 병목을 일으키는 예가 된다.

따라서, 죽는 웹 서버는 일반적으로 성능 모니터링을 하지 않아도 죽는 것을 감을 잡는다. 노련한 엔지니어라면, 시스템이 돌아가는 상황을 조금만 보더라도 "이 시스템은 언제쯤 죽을 것인지" 판단이 서기 마련이다. 사실상, 시스템 성능 모니터를 필자도 거의 이용해 보지 않았으며, 시스템 성능 모니터가 제시하는 값이 사실이라 믿기도 어렵다. 일단 성능을 재는 것은 불확정성의 원리를 따르기 때문이다. 물론, 아주 미션크리티컬한 서버를 특수한 환경에서 시스템 성능을 측정하여, 해당 값을 항상 유지하도록 관리자에게 권고하려면 그나마 좋은 방편일 수 있겠다.

성능상의 문제로 죽는 웹 서버는 일반적으로 다음과 같은 현상을 지닌다.

1. 평소에는 멀쩡하다.
2. 어느날 좀 이상하다.
3. 새벽에 갑자기 죽어버린다.

혹은,

1. 아침에는 멀쩡했다.
2. 그러다 갑자기 죽었다.
3. 재부팅하니 몇시간 간다.
4. 그러다 또 죽었다.
5. CPU/메모리 점유율은 거의 없다.
6. 혹시 해킹이 아닐까? 하고 생각하기 시작한다.
7. 죽는 시간을 대충 감을 잡는다.
8. 죽기 전 재빨리 재시작하는 프로그램을 짜고 입 씻는다.

와 같은 프로세스를 처리하는 것이 일반적이다.

자 그럼 성능 문제로 인해 죽는 웹 서버가 왜 발생할까? 왜 이 서버들이 어느 순간 갑자기 죽게 되는 것일까.

실제로, 이러한 서버군은 평소에 아무리 값을 잰다고 해도 재어지지 않는다. 그러면 이런 서버들을 어떻게 다루어야 할까? 지금부터 말하는 튜닝 포인트라는 개념이 여기서 등장하게 된다.