제니퍼 닷넷 적용 사례 (6) - 잦은 Recycle 문제
교육용 포탈을 운영하는 국내 고객사의 경우입니다.
해당 웹 사이트는 이용자가 별로 변동이 없는 상황임에도 불구하고, 잦은 응답 시간의 저하 현상이 발생했고 그때마다 CPU 사용량도 높았습니다. 제니퍼 닷넷 에이전트 설치 후 그런 현상을 뚜렷하게 확인할 수 있었는데요.
원인은 예전에 소개했던 사례와 유사하게,
제니퍼 닷넷 적용 사례 (3) - '닷넷'이 문제일까? '닷넷 개발자'가 문제일까?
; https://www.sysnet.pe.kr/2/0/1215
빈번한 Recycle로 인한 것이었습니다.
그래서, 개발팀에게 웹 애플리케이션을 자주 배포하는가? 또는 로그 파일을 웹 사이트가 있는 폴더 하위에 쌓고 있는가? 등의 질문을 했지만 모두 '아니오'라는 답만 돌아왔습니다. 그 대답이 못내 의심스러운 나머지 실제로 웹 애플리케이션이 속한 폴더 하위의 변경 파일을 검색해 봤지만 단 하나도 나오지 않았습니다. 심지어, 그렇게 확인하는 와중에도 recycle이 발생하고 있어서 협력사 엔지니어와 저는 그저 '이상하다... 이상하다'라는 말만 연신 내뱉을 수밖에 없었습니다.
그러다가 IIS 관리자를 통해 해당 웹 사이트의 하위로 "가상 디렉터리"가 있는 것을 보게 되었고 그것이 "네트워크 드라이브"로 다른 서버를 가리키고 있음이 발견되었습니다. 그렇습니다, 바로 그 "가상 디렉터리" 내의 파일이 바뀌고 있었던 것입니다.
고객과 이야기해 보니, 그 폴더의 내용은 '콘텐츠 제작자'들이 임의로 편집/저장하는 곳이라는 반가운(?) 설명을 들었습니다.
이로써 모든 수수께끼가 풀리게 되었군요. ^^ '잦은 recycle'은 '콘텐츠 제작자'들의 업데이트 때문이었고 이로 인해 특별할 것이 없는 초당 요청 수를 기록하는 상황에서 recycle의 발생으로 인해 서비스 성능이 급격하게 저하된 것이었습니다.
이러한 설명과 함께 가상 디렉터리를 분리할 것을 조언했고 아마도 이후로는 "
제니퍼 닷넷 적용 사례 (3) - '닷넷'이 문제일까? '닷넷 개발자'가 문제일까?" 시절처럼 다음과 같은 성능 안정화로 들어갔을 것입니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]