성태의 닷넷 이야기
홈 주인
모아 놓은 자료
프로그래밍
질문/답변
사용자 관리
사용자
메뉴
아티클
외부 아티클
유용한 코드
온라인 기능
MathJax 입력기
최근 덧글
[정성태] Roll A Lisp In C - Reading ; https...
[정성태] Java - How to use the Foreign Funct...
[정성태] 제가 큰 실수를 했군요. ^^; Delegate를 통한 Bein...
[정성태] Working with Rust Libraries from C#...
[정성태] Detecting blocking calls using asyn...
[정성태] 아쉽게도, 커뮤니티는 아니고 개인 블로그입니다. ^^
[정성태] 질문이 잘 이해가 안 됩니다. 우선, 해당 소스코드에서 ILis...
[양승조
] var대신 dinamic으로 선언해서 해결은 했습니다. 맞는 해...
[양승조
] 또 막혔습니다. ㅠㅠ var list = props[i].Ge...
[양승조
] 아. 감사합니다. 어제는 안됐던것 같은데....정신을 차려야겠네...
글쓰기
제목
이름
암호
전자우편
HTML
홈페이지
유형
제니퍼 .NET
닷넷
COM 개체 관련
스크립트
VC++
VS.NET IDE
Windows
Team Foundation Server
디버깅 기술
오류 유형
개발 환경 구성
웹
기타
Linux
Java
DDK
Math
Phone
Graphics
사물인터넷
부모글 보이기/감추기
내용
<br /> 정말이지, Microsoft가 IIS 6.0을 설계한 방식에 대해서는 감탄을 자아내게 합니다.<br /> Kernel 단계로 내린 http.sys는 다른 어떤 웹 서버도 따라올 수 없는 경지이죠. 운영체제를 만든 업체로서 시도해 볼 수 있는 커널 드라이버로의 이전은 대단한 성능 개선으로 이뤄집니다.<br /> <br /> (32bit 윈도우즈 기준으로 설명하면)<br /> Kernel 드라이버는 그 특성상 2GB ~ 4GB 가상 메모리에 존재하게 됩니다. 그러면서, 프로세스 전역적으로 매핑이 되어지게 되죠. IIS 5.0/5.1 같은 경우에는 inetinfo.exe가 받아들인 요청을, 그것을 처리해야 하는 worker process로 전달하기 위해서 Named Pipe 또는 TCP/IP를 별도로 사용해야 했습니다. 즉, 부하가 심한 프로세스 간 통신(Inter-process Communication)을 사용해야 했지요.<br /> <br /> 반면에, IIS 6.0에서는 전역적으로 가상 메모리에 매핑되는 커널 단에 존재하기 때문에 결국 받아들인 요청은 w3wp.exe 프로세스 메모리에 매핑되어 있는 효과와 같게 됩니다. 프로세스 간 통신 부하 자체가 없어진 것이죠. 이를 도식화해서 표현한 그림을 아래에 보여주고 있습니다. (2가지 그림 모두 MSDN 사이트에서 가져온 것입니다.)<br /><br /> [그림 1: IIS 5.0 구조]<br /> <img alt="IIS 5.0" src="/SysWebRes/bbs/from_ms_iis5_architecture.gif" /><br /> <br /> [그림 2: IIS 6.0 구조]<br /> <img alt="IIS 6.0" src="/SysWebRes/bbs/from_ms_iis6_architecture.gif" /><br /> <br /> 이렇게 IIS 6.0에 대해서는 여러 가지 칭찬해 줄 만한 것들이 있긴 하지만, 개인적으로 "최고"로 꼽는 기능이 바로 AppPool을 이용한 실제 서비스의 디버깅 환경 구성입니다.<br /> <br /> 아시는 것처럼, 디버깅 프로세스를 attach 시킨 후 예외 상황이 발생하면 프로세스 스케쥴링은 완전히 중지하게 됩니다. 현재 서비스 중인 웹 애플리케이션을 디버깅할 수 없는 원인이 바로 여기에 있죠. 해당 예외가 발생한 스레드 뿐만 아니라, 프로세스에 존재하는 모든 스레드가 중지되기 때문에 사용자들이 전혀 사용할 수 없는 상황이 되어버립니다.<br /> <br /> VS.NET에 원격 디버깅 기능이 있다고 해도 실제로 많은 효용성이 없는 이유가 바로 여기에 있습니다. 서비스 오픈 하기 전의 운영 장비에서 발생하는 특별한 버그를 잡을 때 정도만이 사용될 수 있을 뿐, 일단 서비스가 시작되면 원격 디버깅은 무용지물이 됩니다. 물론, 사용자들이 접속하지 않는 시간대를 선택하면 가능하겠지요. ^^ 그래도, 그런 상황의 개발자는 안스러울 따름입니다. <br /> <br /> 그동안 IIS 5.0/5.1에서는 불가능했지만, IIS 6.0의 AppPool을 이용하게 되면 서비스 중인 웹 응용 프로그램에 지장을 주지 않고도 그와 동등한 환경에서 디버깅을 할 수 있습니다. 벌써, 이 말만 듣고도 감을 잡으셨을 분이 계시겠지만, 간단하게 과정을 설명드리겠습니다.<br /> <br /> <hr /> 1. 임시로 사용될 "웹 사이트"를 만듭니다. 아래와 같이, IP 및 포트는 동일하게 유지면서, 호스트 헤더값만 달리 합니다.<br /> <br /> <img alt="디버그용 웹 사이트" src="/SysWebRes/bbs/iis_debug_new_web_site.png" /><br /> <br /> 2. 만들어진 웹 사이트는 다음과 같습니다. 보시는 것처럼 이름은 "디버그 웹 사이트"로 되어 있으며, 루트 디렉터리 또한 "기본 웹 사이트"와 동일한 곳으로 설정을 했습니다.<br /> <br /> <img alt="디버그용 웹 사이트 - 루트 디렉터리" src="/SysWebRes/bbs/iis_debug_new_web_site2.png" /><br /> <br /> 3. 이제 w3wp.exe 프로세스를 달리 설정할 수 있도록 별도의 AppPool을 만들어야 합니다. 최대한 실제 서비스 환경과 동일하게 하기 위해 AppPool 역시 다음 그림과 같이 "기존 응용 프로그램 풀을 템플릿으로 사용"을 선택해서 만듭니다.<br /> <br /> <img alt="디버그용 AppPool" src="/SysWebRes/bbs/iis_debug_new_app_pool.png" /><br /> <br /> 4. 자, 이제 적절한 URL(예제의 경우 http://debug.sysnet.pe.kr)로 네비게이션을 하면, 새로운 w3wp.exe가 서버에서 구동되게 됩니다. 원래의 서비스는 또 다른 w3wp.exe에서 변함없이 동작하고 있으므로, VS.NET 원격 디버깅으로 새롭게 생긴 w3wp.exe 프로세스에 대해 디버깅을 시작할 수 있습니다.<br /> <br /> <hr /> <br /> 별거 아닌 것처럼 보일 수도 있지만, 실제 운영 서버에서만 발생하는 오류들을 디버깅할 수 있다는 것은 다른 여타의 웹 서버와는 비교할 수 없는 장점을 제공해 줍니다.
첨부파일
스팸 방지용 인증 번호
1517
(왼쪽의 숫자를 입력해야 합니다.)