이전과 마찬가지로 박종명님의 글을 나름 정리해본것입니다.
이전 포스트에서 정리했었던 IIS 5.x 아키텍쳐에 이어 이번에는 IIS 6.0 아키텍쳐 대해 정리해보겠습니다.
하지만 이전 asp 및 asp.net 처리에 대해 알아본것과는 달리 이번에는 asp.net 처리에 대해서만 정리합니다.
(6.0버전 asp처리에 대한 자료가 아직 없어서 이리저리 찾아보고 정리하여 다시한번 포스트하도록 하겠습니다.)
또 한가지로는 IIS 5.x 리소스 처리 아키텍쳐를 보시면 IIS 6.0과는 달리 아키텍쳐의 시작순서가
커널모드가 아닌 inetinfo.exe(사용자 모드)부터 시작하는것을 볼수있습니다.
이는 IIS 버전별 아키텍쳐상의 차이점이며 그림과같이 실제로도 5.X에서는 커널모드부분이
리소스 처리상 쓰이고 있지 않기 때문에 빠진것입니다.
또한 위의표를 보시면 IIS 버전별로 플랫폼 , 커널모드 , 메타베이스의 변화를 한눈에 알수있습니다.
IIS 5.x 와 6.0의 가장 큰 변화라 할수있는것은 각 모드별 처리방식 및 IIS의 메타베이스를 이진에서
XML기반파일로 관리하여 관리상의 이점을 얻을수있으면 바뀐내용에 관해서는 WAS가 실시간으로
반영한다는 점입니다.
iis 5.x
iis 6.0
1. ASP.net 처리 순서
- 6.0기반 Asp.net이 구동되는 기본 아키텍처는 다음과 같은 Out-Process 모델입니다
- 동작 순서
1. Client의 모든 HTTP요청은 5.x가 IIS 메인프로세서인 inetinfo.exe가 받아들이것과 달리
커널 모드에서 작동하는 http.sys 디바이스 드라이버가 받아 들인다.
http.sys 리스너는 Client 요청을 적절한 응용프로그램 풀 요청 대기열에 배치한다.
[
다수의 웹 응요프로그램들이 하나의 으용프로그램 풀을
사용하더라도 응용프로그램 풀의 요청 대기열은 오직 하나이다.
]
2. 응용프로그램 풀은 woker process(w3wp.exe) 와 가상디렉터리(AppDomain)
를 구별한다.
[
IIS의 asp.net 아키텍쳐 부분을 보면 하나의 응용프로그램 풀에 하나의 woker process
가 있고 그 안에 여러개의 AppDomain(가상디렉터리)로 나누어진다.
]
HTTP 요청을 올바른 woker process로 보내기 위해 http.sys 매퍼가 사용하는 논리 프로세스
(논리적인구조를 관리) 경계에 의해 정의되는 (App Pool Request Queue)구성 개체이다.
3. WAS(Web Admin Service)는 메타베이스와 응용프로그램 풀을 관리하는 중추적인
역활을 담당한다.
[
WAS는 workder process를 (생성 , 관리)한다
]
5.x와 마찬가지로 IIS 메인프로세서 inetinfo.exe는 공유되지 않는 svchost.exe의
사용자 모드에서 Local System 권한으로 실행된다.
또한 workder process 의 모니터링 , 리사이클링 등의 관리를 담당한다.
4. IIS 6.0의 메타베이스는 XML 기반의 파일로 관리되며 이 메타베이스의 변경사항을
실시간으로 반영한다.
XML 경로 : C:/WINDOWS/system32/inetsrv/MetaBase.xml
XML 변경예 : 다운로드 제한 AspBufferingLimit="4194304" 4MByte
업로드 제한 AspMaxRequestEntityAllowed="204800" 200KByte
5. 닷넷 웹 리소스를 처리하기 위한 worker process 는 5.x의 aspnet_wp.exe프로세서를 사용하지않고
w3wp.exe를 사용한다.
- w3wp.exe 는 응용프로그램 풀 대기열(그림 2번에 해당) 로부터 요청을 읽어온다.
- w3wp.exe 는 똫ㄴ asp와 같은 닷넷 이전버전의 웹 리소스도 처리한다.
6. inetinfo.exe(5,x의 격리모드)에서 호스트 되었던 aspnet_isapi.dll 은 이제 w3wp.exe 라는
worker process 가 로드한다.
aspnet_isapi.dll 은 CLR 을 로드하고 파이프라인(명명 프로세스 통신)을 시작한다.
7. 기본적으로 모든 활성 웹 응용프로그램들은 하나의 Worker process에서 호스트
(폴링수준)동작 한다. (asp의 격리수준과 같이 처리할수있다.)
그러나 멀티 CPU를 가진 웹 서버라면 다중 Worker process 가 실행되도록 할 수 있다(웹 가든)
machine.config 파일의 <processModel> 섹션의 webGarden 속성을 true 로 설정하고
cpuMask 속성을 비트 마스크값으로 지정
7-1.
- IIS 5.0 : 단일 머신에 둘 이상의 ASP.NET 작업자 프로세서(aspnet_wp.exe)
(멀티 CPU)
- IIS 6.0 : 하나의 응용프로그램풀이 둘 이상의 작업자 프로세서(w3wp.exe) 로 구성되는 경우
1. 기본적으로 하나의 응용프로그램 풀은 하나의 worker process 에서 서비스된다.
그러나 원한다면(성능과 가용성 등을 목적으로) 하나의 응용프로그램풀이 둘
이상의 worker process 에서 서비스 되도록 구성할수 있다.
이렇게 설정하면 하나의 웹사이트가 둘 이상의 worker process 에서 실행되므로
성능과 안정성의 이점을 가질 수 있게 된다.
웹 가든에서의 모든 새로운 요청은 사용 가능한 worker process 간에 작업
로드(workload)를 분배하는 데 사용되는 로드밸런싱 기술인 라운드 로빈 스키마에
따라 worker process 에 할당된다.
]
웹 가든 에서의 상태 관리
- 하나의 웹사이트가 둘 이상의 worker process 에서 실행되도록 웹 가든을 구성하였다면
Application,Session 과 같은 응용프로그램 상태 값은 공유 되지 않을 것이다.
이 경우 상태관리를 worker process 가 해서는 곤란하다.
상태 관리를 worker process 에서 분리하여 Out-of-process Session State 또는
SQL Server Session State 에 게로 상태관리를 넘겨야 하나의 웹사이트내의
모든 자원들에서 응용프로그램의 상태가 공유 될 것이다.
- 매우 하는 일이 많은(매우 바쁜) 응용 프로그램 풀에 다수의 worker process
를 할당하면 각 worker process 가 시작될 때 서버 리소스를 사용하기에
다른 응용 프로그램 풀의 웹
응용프로그램 성능에 영향을 미칠 수 있다. ( 너무 많은 worker process를
구현하는것도 성능상에 문제가 될수있다.)
Prev
Rss Feed