앞서 말한 4가지 중 어떤 것이 주된 원인이 되는지 정형화시키기는 사실 매우 어렵다. 그러나, 일반적으로 분류해 보면, 컴포넌트의 오류와 데이터베이스의 오류가 대부분이다. 혹은 이 둘의 복합적인 양상을 띠게 된다. 일반적으로 컴포넌트 오류로 인한 문제는, 주기적으로 이 컴포넌트와 관계된 오류 메시지가 웹 로그에 나타나므로 그 문제점의 발생 및 수정은 비교적 쉽다. 간혹, 컴포넌트 문제가 아니라 웹 서버 자체의 설치 문제와 관계된 사항들에 의해 시스템 에러를 받기도 한다. 이러한 문제들은 디버거를 사용하여 해결하는 경향이 크다. 웹 사이트 자체를 디버깅 모드로 운영하면서 생기는 여러 결함들을 잡아 낼 것을 일반적으로 권하고 있다. 컴포넌트 오류가 아닌 경우에는 정말 어딘가의 병목이 있어서이다. 이 경우가 ..
ASP Tuning 검색 결과
튜닝 포인트라는 개념은, 실제로 웹 서버의 아주 특수한 부분에 의해 생긴 문제가 전체적으로 확대되어 발생하다는 것이다. 이것은 고속도로에서 흔히 보는 병목 현상과 마찬가지다. 도로 중간에서 사고가 났을 경우, 해당 도로는 마비되지만, 실제로 도로 전 구간이 마비된 것은 아니다. 이런 병목 지점에서 외부의 급격한 리퀘스트를 받게 될 때, 웹 서버는 자기가 처리할 수 있는 양 이상의 값을 받게 된다. 일단 시스템 구조상 이 값은 큐에 삽입된다. 그리고, 큐보다 많이 들어오는 값들은 튕겨 나간다. 이 튕겨 나갈때 나타나는 에러는 Server Too Busy 라는 메시지이다. 그런데, 이 병목 지점이 형성되는 것은 사용 상황과 보조 서버들의 상황, 혹은 여타 외부적인 변수를 매우 많이 받는다. 따라서, ASP ..
Server.CreateObject 구문을 단속하지 않으면 대용량 시스템에 문제가 많다는 사실은 오래 전부터 있어 온 이야기이다. 그러나, 실제 저 문제에 의해 죽는 시스템은 생각보다 많지 않다. 웹 사이트 성능을 측정하면서 많은 부분 간과하는 것이 바로 CPU와 메모리에 지나칠 정도로 집착하는 것이다. 실제로 죽는 웹 서버는 메모리 소요량이 많아서도 아니며, CPU 점유율이 많아서도 아니다. 간혹 CPU 점유율이 많은 서버가 존재할 수는 있겠지만, 이는 데이터베이스 등에서 병목을 일으키는 예가 된다. 따라서, 죽는 웹 서버는 일반적으로 성능 모니터링을 하지 않아도 죽는 것을 감을 잡는다. 노련한 엔지니어라면, 시스템이 돌아가는 상황을 조금만 보더라도 "이 시스템은 언제쯤 죽을 것인지" 판단이 서기 마련..
최근댓글