Fiddler 데모
HTTP.SYS의 Response Cache는 Static 파일(HTML, JPG, GIF 등)에 대해 3/10 secs 요청에 대해 처리 -> Kernel 모드이기 때문에 비용이 절감됨(User Mode로 넘어가는 것 자체가 비용이 많이 듬) -> 중요한 대목
컨텐츠 만료일이 지나기 전에는 페이지 내용이 갱신되지 않음(서버에 요청하지 않아 서버 부담이 줄어듬)
[Recycling]
문제가 생기는 것을 예방하기 위해: 앱이 문제 없이 개발되었다는 것을 장담하지 못하기 때문
사용자가 적다면 Recycling 하더라도 장애를 느끼지 못함
그룹웨어의 경우 지연을 느낄 수도 있음
w3wp가 실행 중인 경우 재생을 하면 기존 것은 실행이 되고, 큐가 다 빠져나가면 새 w3wp를 통해 접근이 됨.
문제는 recycle되는 timeout(기본 90초) 동안 큐가 다 빠지지 않으면 w3wp를 다시 만들어서 동작.
그렇게 하더라도 실패한 경우 Pool이 Stop됨.
503 오류를 봤을 때 해당 AppPool 설정을 확인해
- Rapid-Fail Protection이 True로 되어 있는지 확인 -> False로 바꿈,
- web.config에서 Compilation Debug 또한 False로 바꿈
기본적으로 Recycling에서 사용하는 Overlapping 방식을 사용하지 않게 할 수 있는데, 그러면 Recycling 중 사용자가 오류를 만날 수도 있음.
Memory Leak이 생기고 이유를 못 찾을 때 제한을 둘 수 있음. 메모리를 많이 사용해서 서버에 문제가 있을 수 있음.
- Private Memory Limit: 최소 500MB 정도는 설정해야 함 -> 이것을 설정해서 문제가 생겨 장애가 생긴 경우도 있었음
- 작게 잡으면 Recycling이 자주 일어나 문제가 될 수 있음
- Virtual Memory Limit
드디어 [Best Practice]
OS에 대한 Best Practice
백그라운드 서비스를 우선하도록 설정
- WAS와 WWWPublishing 서비스가 Service 형태로 동작하기 때문
- 우선 순위를 몰아주는 내용
DebugDiag는 문제가 생겼을 때 원인을 찾을 수 있으므로 서버에 설치해 두자.
최소 디스크 용량의 10%는 남겨 두어야 한다.
IIS 로그는 반드시 C 드라이브 외에 다른 드라이브로.(디스크 박스도 분리하면 좋다)
성능으로만 봤을 때 Server Core를 사용하면 좋다.
Static 자료들은 별도의 서버로 빼면 좋은데 …
ARR(Applicatipn Request Router) = L7과 같은 역할
- Reverse Proxy 역할을 함.
- Disk Caching을 함
w=w2012R2
w(arr)=L4
w2(arr)=L7
w3(arr)=L7
w4=web1
w4=web2
ARR은 IIS의 Extension임
보안을 위해 WAS는 DMZ 안쪽으로 몰아줘야.
익명 액세스가 가능한 이미지 파일과 같은 경우 굳이 HTTPS로 갈 필요가 없음 HTTP로 설정하는 것이 좋음
[ASP.NET]
이벤트 로그: ASP.NET에 대한 로깅이 남아 있음(없을 수가 없다고 …)
- 파라미터가 잘못 들어갈 수 있기 때문에 나올 수 밖에 없음
- 자료형이 다 른 내용이 들어오는 문제 등 때문에 발생
컴파일이 되지 않은 ASPX가 들어왔을 때, 컴파일을 거친 후 실행되는 속도 -> 실행 속도도 느리고, 메모리도 더 많이 사용하게 됨
SharePoint의 경우 webResources.axd 핸들러가 캐싱이 되지 않은 문제
[백신 예외 처리]
%windir%\Microsoft.NET\Framework##\Temporary ASP.NET Files
%windir%\system##\inetsrv
%systemdrive%\inetpub
[압축]
정적, 동적 모두에 압축을 해야 함
[configuration 계층 구조]
Machine.config
rootweb.config ==> ASP.NET 에 대한 설정
ApplicationHost.config
Application Web.config (optional)
Application Web.config (optional)
하위 폴더가 많아서 속도가 느릴 때(파일 서버 등)
applicationhost.config을 메모장으로 열어 allowsubdirconfig 을 false로 만들어야 함.(최상위 하나에만…)
※ Web root folder가 NAS에 있고, 그곳에 web.config이 없는 경우가 많기 때문에 위와 같이 설정해야 함.(web.config에는 해당 설정이 없음)
IIS는 하위 디렉토리가 많아지면 속도가 떨어짐(윈도우의 파일 검색 알고리즘이 UNIX에 비해 성능이 좋지 않음)
[Security]
Directory Browsing 사용 안 함
AppPoolIDentity를 사용하는 것이 가장 좋다.
AppPoolID가 아닌 Domain Admins을 포함한 계정을 사용한 계정의 경우 보안 감사에 걸림
NTFS Permission을 제대로 설정해야 함
NTFS 권한을 왜 보는가?
- 사용자가 index.aspx를 요청하게 되면 IIS에 가서 디스크에 파일이 존재하는지 확인
- 익명 인증에 대한 Anonymous 권한 체크를 먼저 하게 됨, 권한이 없으면 체크를 할 수 없음
[IISReset vs recycle]
Session
L4에서 잘못해서 Hang이 되면 IISRESET을 해야만 L4와 묶여 있던 세션이 끊김.
Recycling을 해서 해결이 되지 않는 경우 IISRESET을 해줘야 하는 경우가 생김.
- appcmd list wp로 PID 확인
w3wp.exe recycle 90 sec timeout
새로운 w3wp.exe 이 생겨서 해결이 되면 DB 쪽을 확인
(AppPool Recycle을 했는데 느리면 DB에 Blocking 되었을 가능성 존재.(Table Lock 등))
재생을 했지만 계속 느린데 IISRESET을 하고 나서 빨라지면 네트워크 문제일 가능성이 있음.
[관리]
기능 위임은 국내에서는 무용지물(아무리 권한이 많아도 Pool Recycling에 대한 권한은 부여되지 않음)
[백업]
ApplicationHost.config은 자동으로 백업된다고 함.
C:\inetpub\History 에 가보면 applicationhost.config이 있고, 이를 system32\inetsrv\config 에 덮어쓰면 바로 이전 것으로 복원 가능. 오~~ 좋다.
[실습]
밥먹고 실습 시작
WCAT 설치
DebugDiag 설치
로그 파서 설치
환경 변수에 해당 폴더 추가
로그 파서로 inetpub 폴더의 로그를 파싱
한번더~
aspx 문서의 상단에 Trace=True를 추가
Default Web Sites에 대해 실패한 요청 추적 구성 선택
안좋은 UX.
다시 규칙을 보자
[성능 모니터]
WebServices -> Current Connections
Current Connections가 만약 1000이면 /4를 해서 실제 접속량을 알 수 있음.(Modern browser들이 한 번에 Connection을 4개 정도 가져감)
Connection은 2분 뒤에 연결이 끊어짐
- WebServices
- Current Connections
- ASP.NET 카운트(설치된 버전에 따라)
- Request Wait Time: 트래픽이 많으면 늘어나고, 적으면 줄어들어야 하는데… 그런 패턴이 아니라 트래픽이 많은데 늘어나지 않고, 적은데 줄어들지 않는 상황이 생기면 DB 등을 살펴볼 필요가 생긴다.
- Requests Queue: 평균 10 이상이 되면 서버가 죽음 -> 그룹웨어는 조금 더 값이 클 수 있다.
- Application Restarts: AppPool 안의 논리적으로 쪼개진 Application Domain에서 어떤 Domain이 Re-Compile이 되면서 다시 생기는 상태 -> 좋은 징조는 아님
- Requests Rejected: 더 이상 IIS에서 Request Queue를 처리를 못할 때. 사용자들이 그 숫자만큼 오류를 보게 된다.
- Memory
- Available Mbytes: 사용 가능한 메모리. Top 20% Bottom 20%… 메모리나 CPU가 해당 리소스의 20% 보다 적게 남으면 문제가 있다고 판단.
- Process
- Handle Count(W3WP)
- Private Bytes(W3WP):
- Thread Count(W3WP)
- System
- Process Queue Length
아키텍처상으로 Queue가 가장 중요
Requests Queue, Requests Rejects -> 0이면 정상
※ 선택한 카운터가 20개 미만이면 1초
그래프보다 수치가 보기 좋을 수도 있음.
IIS에서 작업자 프로세스에 가서
작업자 프로세스(Worker Process)의 상태 확인 가능, 하지만 구체적인 처리는 어렵다
[NP .NET Profiler]
웹 서버에 장애가 생겨 L4에서 제외한 웹 서버에 설치해서 쓴다고 함. 운영중인 서버에서 동작시키는 것은 무리가 있다고.
IIS 서비스를 중지하게 됨.
이 상태에서 스트레스 준 뒤(stress.bat)
덤프 수집
process explorer
TCP View : 마치 netstat 처럼 인터넷 패킷이 있는 것을 모두 잡아줌
※ 로그를 볼 때는 +09:00 이기 때문에 GMT 기준이라면 9시간을 더해야 함.
[Network Monitor]
Source와 Destination 설정
ipv4.address==145.55.30.100 으로 필터링하고 apply 하면 서버와 내 PC 간의 통신을 확인 가능
Time Offset을 보고 통신이 지연되는 구간이 있음(앞뒤 로그를 보고 값 차이가 많이 나는 곳) 이걸 확인해야 함
SYN, ACK 등의 매커니즘을 공부해야 도움이 됨
Netmon Essentials for Exchange Support Professionals 문서가 좋음
검색 엔진에서 Netmon 사용법으로 검색
IP를 보고, 시간차를 보고, 메시지를 본다 -> NETMON 사용의 모든 것
