< eun2jong.com > 은이종

다음 글은 MSDN의 다음 글을 발번역한 것이다.

> Optimizing IIS Performance

IIS 7.0을 기준으로 하고 있지만, 생뚱 맞게 ASP 가이드가 웬말이냐...

어쨋던 ASP.NET에서도 유사한 설정이 있으니 참고할만하며, ASP.NET 가이드 부분은 실질적 도움이 된다.

IIS 성능 최적화

IIS 성능 향상을 위한 구성 옵션 적용

IIS는 성능에 영향을 미치는 다양한 구성 매개변수를 노출한다. 이 토픽에서는 이러한 매개변수 몇 가지를 설명하고 IIS 성능 향상을 위해 필요한 매개변수 설정의 일반적인 지침을 제공한다.

* 로그는 필수적인 정보만 저장하거나 전혀 사용하지 않도록 하라.

프로덕션 환경에서는 IIS 로깅을 최소화 하거나 비활성화 해야 한다. 다음 단계를 따르라.

단계 요약: IIS 관리자>해당 사이트>로깅>사용 안 함 설정

* 프로덕션 환경에서는 IIS ASP 디버깅 기능을 비활성화 시켜라.

프로덕션 환경에서는 IIS ASP 디버깅을 사용하지 말아야 한다. 다음 단계를 따르라.

단계 요약: IIS 관리자> 사이트> ASP> 컴파일> 디버깅속성> 서버 쪽 디버깅 사용, 클라이언트 쪽 디버깅 사용 항목을 false로 설정

ASP.NET 응용프로그램 또는 웹 서비스의 디버깅 비활성화는 web.config 파일의 <compliation debug=”false” />로 설정

* 프로세서 당 ASP 스레드 제한 값을 조정하라.

ASP 스레드 제한 속성은 프로세서 당 생성할 수 있는 작업 스레드의 최대값을 나타낸다. 이 값을 프로세서 사용률이 적어도 50% 이상 충족할 때까지 값을 높여라. 이 설정은 웹 응용프로그램의 확장성과 전반적인 서버의 성능에 많은 영향을 미칠 수 있다. 이 값은 동시에 실행할 수 있는 ASP 요청의 최대 값을 정의하기 때문에 당신의 ASP 응용 프로그램이 외부 구성요소로 확장된 요청들을 하지 않는 한 기본 값을 유지해야 한다. 확장된 요청을 하는 경우라면, 값을 높이는 것이 좋다. 이렇게 하면 서버가 더 많은 동시 요청을 처리하기 위해 더 많은 스레드를 만들 수 있다. 기본 값은 25이다. 이 속성의 최대 권장 값은 100이다. 다음 단계를 따르라.

단계 요약: IIS 관리자>서버>ASP>제한속성>프로세서 당 스레드 제한 값을 원하는 값으로 설정(기본: 25)

IIS 7.0의 ASP 제한 설정에 대한 더 더 많은 정보는 다음 URL에서 확인

http://www.iis.net/configreference/system.webserver/asp/limits

노트1> 이 속성은 서버 레벨에서 적용할 수 있기 때문에, 값의 수정은 서버의 모든 웹 사이트에 영향을 미친다.

노트2> IIS 7.0의 이 속성은 IIS 6.0의 ASPProcessorThreadMax ASP Metabase 세팅을 대체한다

* ASP 큐 길이 조정하라.

이 값을 설정하는 이유는 ASP 요청 큐가 찼을 때 HTTP 503(Server Too Busy)가 반환되는 빈도를 최소화 하면서 좋은 응답성을 보장하기 위함이다. 만일 큐 길이가 너무 낮으면, 서버는 503 오류를 자주 뱉어 내게 될 것이다. 반면 큐 길이가 너무 높으면, 요청이 큐에 대기하는 동안 사용자는 서버가 응답하지 않는다고 인식할 것이다. 높은 트래픽 상황에서 큐를 주의 깊게 살펴보고 피크 타임의 대기 요청 수를 기록하고 이 값보다 높은 값으로 큐 길이를 설정해야 한다. 응답 시간을 보장하고 단기적인 스파이크를 처리하기 위해 큐를 사용하며 지속적인 예상치 못한 스파이크가 발생할 때 과부하를 방지하기 위해 이 값을 조정한다. 당신이 큐 길이 제한에 대한 데이터가 없는 경우, 총 스레드 큐의 일대일 비율로 설정하는 것을 권장한다. 예를 들어 4개의 프로세서 환경에서 프로세서당 ASP 스레드 수의 제한 값이 25일 경우 4 * 25 = 100으로 설정하고 여기서부터 출발하는 것이다. 큐 길이 조정을 위한 다음 단계를 수행하라

단계 요약: IIS 관리자>서버>ASP>제한 속성>큐 길이에서 원하는 값 지정

노트1> 이 속성은 서버 레벨에서 적용할 수 있기 때문에, 값의 수정은 서버의 모든 웹 사이트에 영향을 미친다.

노트2> IIS 7의 ASP 큐 길이 속성은 IIS 6.0의 AspRequestQueueMax ASP Metabase 셋팅값을 대체한다.

* MaxPoolThreads 레지스터리 항목을 조정하라.

이 값은 CPU당 풀에 생성할 수 있는 스레드 수를 나타낸다. 풀 스레드는 들어오는 요청을 감시하고 처리한다. MaxPoolThreads 수는 ISAPI 응용프로그램에서 소비하는 스레드는 포함하지 않는다. 일반적으로 프로세서당20개 이상의 스레드를 생성할 필요는 없다. 이 설정은 레지스터리HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\에 REG_DWORD 값으로 지정할 수 있으며 기복 값은 4로 설정되어 있다.

* WCF 서비스 트레이싱을 비활성화 시켜라.

프로덕션 서버에 WCF 구성 설정 편집기(SvcConfigEditor.exe)를 사용하여 트레이싱을 비활성화 시켜라.

이 툴에 대한 더 자세한 정보는 다음 url에서 확인

http://msdn.microsoft.com/en-us/library/ms732009.aspx

* IIS 7.0 통합모드를 위한 ASP.NET MaxConcurrentRequests를 구성하라.

IIS 7.0 통합모드에서 ASP.NET 2.0이 호스트 되는 경우, 스레드 처리가 클래식 모드나 IIS 6.0과는 다르게 처리된다. 이 경우 ASP.NET 2.0은 동시 실행 스레드 수 대신 동시 실행 요청 수를 제한한다. 동기 시나리오에서는 요청 수가 스레드 수와 동일하기 때문에 간접적으로 스레드 수를 제한할 것이다. 그러나 비동기 시나리오에서는 스레드 수 보다 훨씬 더 많은 요청이 있을 수 있기 때문에 요청수와 스레드 수가 많이 다를 수 있다. ASP.NET 2.0이 IIS7.0 통합모드에서 실행될 경우, machine.config 파일의 httpruntime 요소의minFreeThreads와 minLocalRequestFreeThreads 값이 무시된다. IIS 7.0 통합모드에서는 레지스터리의HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0에 있는MaxConcurrentRequestsPerCPU 값에 의해 CPU당 동시 요청 수를 결정하게게 된다. 기본적으로 이 레지스터리 키는 존재하지 않으며 기본 값은 CPU당 12개 이. net framework 3.5 SP1에는 aspnet.config 파일을 통해IIS 응용프로그램 풀 구성을 할 수있는 2.0 바이너리에 대한 업데이트가 포함되어 있다. 이 파일은 통합모드에서만 유효하다.(IIS 6.0 혹은 클래식 모드일 경우 이 파일의 설정은 무시된다.) 이 새로운 설정 파일의 기본 값은 다음과 같다.

<system.web>

   <applicationPool maxConcurrentRequestsPerCPU="12" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/>

</system.web>

경험상으로 봤을 때, MaxConcurrentRequestsPerCPU 값은 5000 정도로 큰 값으로 설정해야 한다.

IIS 7.0 통합모드에서는 machine.config 파일의 processModel 요소의 maxWorkerThreads, maxIOThreads 설정은 본질적으로 실행중인 요청 수를 제어하는데 사용되지 않는다. 그러나 여전히 ASP.NET에 의해 사용되는CLR 스레드 풀의 사이즈를 제어하는 데는 사용된다.

machine.config 파일의 processModel 섹션의 autoConfig 설정이 true(기본 값)일 경우, 응용프로그램 풀에(논리적인) CPU당 최대 100까지의 스레드(MaxWorkerThreads)를 생성할 수 있다. 2 듀얼 코어 CPU일 경우에는 400개가 된다. This should be sufficient for all but the most demanding applications.

IIS 7.0과 6.0의 ASP.NET 스레드 활용법을 위한 더 많은 정보는 다음 사이트에서 확인 하시길.

http://msdn.microsoft.com/en-us/library/ee377050%28v=bts.10%29.aspx

* HTTP 압축을 사용하라.

대역폭을 보다 효율적으로 사용하고 싶다면 IIS HTTP 압축을 활성화하라. 압축을 사용하면 콘텐트가 로컬 저장소에 있거나 UNC 리소스이거나 관계없이 (압축을 허용하는) 브라우저와 IIS 간 더 빠른 전송 효과를 볼 수 있다.

(단계 요약: IIS 관리자>서버(또는 사이트)>압축>원하는 압축 옵션 설정)

 
http://m.mkexdev.net/265
참고하였습니다. 

예) 패스워드 스크립트 파일을 pass.sh 라고 설정했을시 해당 파일을 열어서 편집

vi pass.sh

  www.aaa.com:      443)          echo "aaaaa";;  

   도메인 부분       포트부분      패스워드 부분

+20170308 추가분

현재 Apache 2.2 버전 이상부터는 SNI지원으로
443 Port 1개에 2개이상의 도메인이 가능한 상황
그래서



등의 형태도 가능하니 꼭 설정할때 httpd-ssl.conf Port 확인



Copy&Paste 용

#!/bin.sh
case $1 in
 www.aaa.com:443) echo "aaaaa";;
 www.bbb.com:444) echo "bbbbb";;
esac

exit0

==================================================================================== 

#!/bin.sh
case $1 in
 www.aaa.com:443) echo "aaaaa";;
 www.bbb.com:443) echo "bbbbb";;
esac

exit0
====================================================================================

Nginx SSL 설정

nginx.conf
-------------------------------------------------------
  server {

 ---------------------------------------------------------

 참고로
Nginx 는 Apache와 다르게 SSLPassPhraseDialg 기능이 없다
비밀번호 자동입력은 불가능하고 방법은

아래처럼 인증서 비밀번호 자체를 제거해야한다.
(Private 인증서나, 상용 인증서 둘 다 가능)

cp ur_domain_name.key ur_domain_name.key.bak

openssl rsa -in  ur_domain_name.key.bak -out ur_domain_name.key

 

 

핫이슈를 넘어서 이제는 당연시 되고 있는 클라우드 시스템(Cloud System). 클라우드를 구성하는 요소 중에서 가상화(Virtualization) 기능은 빠질 수 없는 핵심 요소 중에 하나라고 할 수 있다. 가상화를 하기 위해서는 하이퍼바이저(Hypervisor, Virtual Machine Monitor이라고도 한다)라는 별도의 시스템 프로그램이 필요하다. 이미 서버단의 가상화는 자원의 효율성 측면에서 기본이 되어가고 있다.

가상화 분야에서 '가상화 대상이 되는 시스템'을 의미하는 용어는 여러 용어가 횬재되어 사용되니 정리하고 넘어가자. '가상머신(Virtual Machine)'-약어로 'VM', '도메인(Domain)'-약어로 'Dom', '게스트(Guest)' 이들 용어 모두가 '가상화 대상이 되는 시스템'을 의미한다. '게스트 운영체제'와 대비되는 '호스트 운영체제'는 가상화 프로그램을 실행하는-즉, 가상화 하지 않은- 실제 운영체제를 의미한다. 호스트 운영체제는 Type 2에서만 존재하는데, Xen은 Type 1 하이퍼바이저이므로 호스트 운영체제가 존재하지 않는다. Type 1은 하이퍼바이저 위에 모든 도메인이 동작하는 방식이고, Type 2는 호스트 운영체제에서 가상화 프로그램을 실행하여 게스트를 실행하는 방식을 말한다.

<그림 1. Type 1과 Type 2 하이퍼바이저>

대표적인 오픈소스  하이퍼바이저로는 Xen과 KVM이 있다. Xen은 'Xen and the Art of Virtuallization'이라는 가상화 분야에서 매우 유명한 논문과 함께 대표적인 반 가상화(Para Virtualization) 하이퍼바이저로 등장하였다. 반 가상화는 게스트 운영체제 일부를 수정하는 시스템을 말한다. 반 가상화의 대비되는 전 가상화(Full Virtualization)은 게스트 운영체제를 수정하지 않고 실제 머신과 동일하게 사용하는 것을 말한다. Xen의 반 가상화의 게스트 운영체제는 특권 명령을 실행하려면 '하이퍼콜(Hypercall)'로 하이퍼바이저에게 서비스를 요청하는 해야 한다. 운영체제에서 어플리케이션이 커널에게 '시스템 콜(System Call)'로 서비스를 요청하는 방식과 동일하다. 실제로 하이퍼 콜은 시스템 콜과 동일한 방식으로 구현되어 있다. 서비스를 요청이 (어플리케이션 -> 커널) 인지, 아니면 (게스트 운영체제 -> 하이퍼바이저) 인지에 따라 용어가 달라질 뿐이다.

Xen에는 도메인 0라는 특수한 도메인이 존재한다. 도메인 0는 실제 물리 디바이스와 통신하는 디바이스 드라이버가 있고, 각 도메인을 제어한다. 도메인 0는 기능상 Type 2 하이퍼바이저의 호스트 운영체제와 유사하지만, Type 2에서 호스트 운영체제는 하이퍼바이저를 하나의 어플리케이션으로 관리하고, Type 1에서 도메인 0는 하이퍼바이저에서 하나의 도메인으로 관리되므로 전혀 의미가 다르다. Xen 반 가상화에서 장치 입/출력을 예를 들면, 각 도메인은 하이퍼 콜로 Xen 하이퍼바이저에게 입/출력 요청을 하게 되고, Xen 하이퍼바이저는 이를 도메인 0에게 전달하여 실제 장치와 입/출력을 하게 된다. 그러면, Xen 하이퍼바이저는 입/출력 결과를 다시 입/출력을 요청한 도메인에게 입/출력 결과를 응답한다. Xen의 반 가상화 입/출력을 할 시에 사용되는 매커니즘으로 I/O 링, 이밴트 채널(Event Channel), 프론트-앤드/백-앤드 드라이버, 그랜트 테이블(Grant Table), XenStore등이 있지만 모두 설명하려면 내용이 너무 길어지니 그런 것이 있다고만 알고 넘어가도록 하자.

<그림 2. Xen 아키텍처>

KVM은 Xen과 다른 관점에서 가상화를 제공한다. KVM은 가상화를 제공하는 하이퍼바이저를 메모리 관리자나 파일 시스템등과 같은 커널의 '서브 모듈'로 취급한다. 개인적으로는 가상화 기능이 운영체제의 기본이 되어가는 시점이므로 KVM과 같은 접근 방식이 옳다는 생각이다. KVM에서 가상화를 제공하기 위해서는 한 가지 전제 조건이 붙는데, 사용하는 CPU에서 HVM(Hardware Virtual Machine) 기능을 제공해야 한다는 점이다. 과거 가상 메모리(Virtual Memory)를 지원하기 위해 CPU에서 페이징(Paging) 기능을 하드웨어 차원에서 제공했던 것과 같이, 최근 가상화 기능이 많이 사용되므로 CPU에서 가상화 기능을 하드웨어 차원에서 제공해주는 것이다. x86 아키텍처의 HVM으로는 Intel의 VT-x와 AMD의 SVM가 있다. 같은 x86 아키텍처이라고 할지라도 가상화 기능은 벤더마다 다르므로 벤더별로 구현해야 하는 단점이 있다. 최근에는 임베디드 시스템에서 주로 사용되는 ARM 아키텍처도 Cortex-A15 이후로 가상화 확장(Virtualization Extension) 기능이 추가되어 HVM을 제공한다.

<그림 3. KVM 아키텍처>

이렇듯 Xen과 KVM은 가상화를 제공하기 위해 애초에 접근 방법이 다르고 물론 구현도 매우 달랐'었다'. 당연히 프로젝트 초창기에는 Xen과 KVM 양 진영에서 서로 각자가 좋다고 주장하며 많이 싸웠다. 상용 하이퍼바이저인 VMWare, MS 하이퍼-V와 오픈 소스 Xen, KVM 등의 '하이퍼바이저 전쟁'이 한창 이다. (Xen의 반 가상화는 VMWare의 바이너리 변환(Binary Translation)에 대비되는 기술이다. 초창기에는 기술적인 측면에서 '반 가상화 Vs. 바이너리 변환'로 대립하였다.)

여기서 중요한 점은, Xen과 KVM은 오픈 소스라는 것이다. 원한다면 누구나 소스를 볼 수 있고, 필요에 따라 코드를 수정 할 수 있다. 리눅스가 BSD의 장점을 흡수하면서 발전해온 것처럼, Xen과 KVM도 서로 장점을 흡수하면서 발전해 나가고 있다. 이미 Xen도 매우 오래전부터 전 가상화를 지원해 왔다. Xen의 전 가상화는 KVM과 같이 HVM 기능을 활용하여 구현되어 있다. 즉, Xen의 전 가상화 기능만 떼고 봤을 때는 KVM이나 Xen이나 유사하다는 것이다. 더구나 VMWare나 KVM도 반 가상화 기능을 제공한다. Xen의 하이퍼 콜, VMWare의 VMI등의 각 하이퍼바이저 별로 다르게 구현된 반 가상화 인터페이스를 일관된 인터페이스로 추상화 하기 위하여 Paravirt Operation가 등장하였다.

결론은 이제는 가상화 시스템을 구축하기 위하여 어떤 하이퍼바이저를 선택하던간에 비슷하다는 것이다. Xen의 "하이퍼바이저 위에서 모두 놀아라." 라던지, KVM의 "커널이 곧 하이퍼바이저이다." 라던지 현 시점에는 더 이상 의미가 없어졌다. 돈이 좀 들더라도 높은 완성도에 기술 지원을 바라면 VMWare가 정답이고, MS빠라면 하이퍼-V가 정답이다. 무료로 필요에 따라 소스 수정도 할 생각이면 Xen이나 KVM 어느 것도 괜찮다. 그냥 익숙한 것을 선택하면 된다. 지금 사용 중인 하이퍼바이저가 다른 하이퍼바이저보다 성능이 떨어진다면 하이퍼바이저를 의심 할 것이 아니라 튜닝이 잘못 된 것이므로 담당 엔지니어의 능력을 의심해 보라.

원본 위치 <http://onestep.tistory.com/94>

윈도우에 숨겨진 midi 파일!

윈도우7 기준으론

C:\Windows\Media에 파일들이 있다.

flourish.mid

onestop.mid

추천

HKEY_CURRENT_USER\Software\Microsoft\CTF\LangBar

the ShowStatus value becomes 0 when we select the option "Floating on desktop"

the ShowStatus value becomes "4" when set to "docked on the taskbar"

the ShowStatus value becomes "3" when set to "hidden" which is the default.


기타 설정해두면 편리한 옵션이다.

export PS1="[\u@\h \w]\\$ "
--------------------------------
권한 부여

pig 를 검색하면 아래 Pig Toolbox가 검색됩니다.

설치를 누리면 완료.