HTTP Compression

HTTP Compresssion
요즘과 같이 네트웍이 빨라진 시대에 HTTP 압축이 무슨 도움이 될까? 하는 생각도 하겠지만, 실상은 여전히 유용하다고 볼 수 있다. google.com이나, yahoo.com 혹은 유수한 포털의 Http Header 정보를 보게되면, HTTP 압축을 사용하고 있는 것만 보더라도 그것을 입증해 준다.

이 글로 HTTP Compression을 어떻게 사용하는지, 설정은 어떻게 하는지 알아 보자.
우선 HTTP 압축을 위해서는 Web Server와 Web Client(Browser) 두 영역에서 압축을 지원해 주어야 한다. 오늘날 대부분의 WEB Server(IIS, Apache, Tomcat...)는 이 HTTP 압축을 지원하고 있고, 클라이언트인 IE 나, FireFox 또한 기본적으로 압축을 지원하고 있어 HTTP 압축을 쉽게 사용할 수 있다.


HTTP Compression Activity

일단 HTTP 압축을 사용하기 위해 Client 와 Server 간에 어떤 행위가 일어나는지 살펴보자.
HTTP 압축을 사용하기 위해 Client가 해야 할 행위는 HTTP Header 에

Accept-Encoding: gzip, deflate

위 속성을 정의해 주면 끝이다. 이것은 하나의 약속으로, 클라이언트가 압축을 받아들일 준비가 되어있다는 의미이다. 즉, 브라우저에 압축을 해제할 수 있는 모듈이 탑재되어 있어, 서버가 HTTP 를 압축해서 던저줘도 된다고 선언하는 것이다.
오늘날 대부분의 클라이언트(IE, FireFox)는 이를 자동으로 설정한다.

그리고 나서, 서버가 할 행위는, 요청을 받아 들이고 처리해서 그 내용을 gzip 을 통해 압축해서 다시 클라이언트에 전송해주는 일이다. 이때 Server 는 HTTP Header에

Content-Encoding: gzip

을 설정해서 client 로 보내주며, client 는 이에 대응하는 압축해제를 하게된다.


HTTP Compression Configuration

여기에서, HTTP Compression 설정은 IIS 6.0기준으로 설명하기로 하며, Apache나 Tomcat, Was에 대한 설정은 별도로 수행해 보라.

IIS에서 HTTP 압축은 설정은 "인터넷 정보서비스(IIS) 관리"에서 설정할 수있다.

"IIS 관리"에서 --> "웹사이트"를 선택하고, 속성(properties) 선택 --> "웹사이트 등록정보" 화면창에서 "서비스" 탭을 선택한다. 다음과 같은 화면이다.

















하단에 HTTP 압축 항목이 보인다.
두가지 체크박스가 있는데, "정적 파일 압축"은 확장자가 html, htm, txt 같은 정적파일을 압축하는데 사용되며, "응용 프로그램 압축"은 기본적으로 asp, dll, exe 파일을 압축하는데 사용된다.
이 U.I 에서 설정된 정보는(다른 IIS 설정정보도 마찬가지겠지만..) %windir%\system32\inetsrv\MetaBase.xml 파일에 저장된다.

사용하고자 하는 항목을 체크하고 "확인"을 선택하면 이제부터 HTTP 압축을 사용할 수가 있다.이것이 끝이 아니다, 지금부터는 안좋은 소식이다.
ASP.NET 사이트를 운영하고 있고 Fildder 같은 유틸로 오고가는 HTTP Header를 보면 IIS에서 HTTP 압축을 설정했지만 여전히 내용이 압축되지 않는다는 사실을 알게된다. 정말 당혹스럽다.왜그럴까?
위에서 잠깐 언급해지만, "응용프로그램 압축" 의 기본 확장자가 asp, dll, exe 임을 주목하자.
맞다. 참으로 어처구니 없게도 aspx 가 제외되어 있다.
버그인지... 그들의 의도를 알수 없는 대목이다. 어쨋든 인간이 하는일에 있어 완벽한 일이 어디 있겠는가? 실수라고 생각하자. 그러는 것이 건강한 이성을 유지하는 길이다.

어쨌든, 원인을 알았으니 해결할 수 있다. 지금 부터는 손의 수고가 필요하다(사실 결정적인 상황에서 손이 필요한 경우가 종종있다.)
위에서 IIS 설정값이 %windir%\system32\inetsrv\MetaBase.xml 에 저장된다고 했다.
이 파일을 열어 다음과 같은 엘러먼트를 찾는다.



어트리뷰트중 HcScriptFileExtensions aspx 확장자를 추가한다. 내 경우는 다음과 같다.



그리고 한가지 더, HcDynamicCompressionLevel 이란 속성이 있는데, 이것은 압축 수준을 결정한다.
0~10 까지 설정할 수있다. 압축율이 높다면, 응답성능이 조금 떨어지는 것은 당연하다.


XMLHTTP 와 HTTP Compression

XMLHTTP 는 크게 두가지로 나뉜다.
wininet.dll을 사용하는 XMLHTTP, winhttp.dll을 사용하는 ServerXMLHTTP이다.
차이점은 차후에 알아 보기로 하고, 서버에서 사용하는 ServerXMLHTTP는
HTTP Header를 설정할 수 없기에 압축을 지원하지 않는다.

하이퍼스레딩 (Hyper-Threading) 사용할 것인가 말것인가?

SQL Server 혹은, .NET 이나 J2EE applicadtion 환경에서 인텔 계열 CPU를 사용할 때 Hyper-Threading이 과연 어떠한 영향을 미치는지 생각해 보도록 하자

• Hyper-Threading이란?

먼저 Hyper-Threading 이라 부르는 이 인텔의 cpu 기술은 multi-thread기술을 CPU layer에 도입한것이지만 실상 이것과는 다른다. 이것은 시분할 처럼 thread의 인터리빙 방식이 아니라 cpu 아텍처상 길게 늘어진 pipeline을 통해 있는 비어있는(놀고) 사이클을 다른 프로세스에게 사용할 수 있는 기회를 주는 것이다. 다시 말해서 현재 어떤 쓰레드가 RAM 액세스나 I/O 액세스 같은 오랜 시간이 걸리는 작업이 끝나기만을 기다리고 있다면 이를 다른 쓰레드에 할당하여 cpu의 활용도를 높이는 기술이다.
통상 Hyper-Threading을 사용하면 5% ~ 15%의 성능 향상을 기대할 수 있다.
하지만 이게 다가 아니다. 이 기술의 이면에는 조금은 깊게 생각해야할 성능적 문제가 자리잡고 있다.

• Hyper-Threading의 성능문제

위에서 설명한 대로 hyper-threading 기술은 놀고있는 cycle를 다른 쓰레드에게 할당해주는 방식이기에 마치 2개의 cpu 처럼 보일 뿐이지, 물리적으론 하나다. 그 말은 L1&L2 캐쉬를 공유한다는 의미이다. (마치 다중 thread가 프로세스내의 메모리를 공유하는것가 동일하다)
문제는 여기에서 출발한다.
Thread는 크게 두개로 나눌수 있다. 하나는 사용자의 요청을 처리하는 worker thread이고 , 다른 하나는 system thread로 백그라운드로 수행되는 쓰레드인데, GC나 Lazy writer 같은 것이 이에 해당한다. 왜 이것을 말하냐 하면, worker thread는 비교적 작은 단위 작업을 처리하는데 비해 백그라운드 쓰레드는 대용량 메모리나/object/cache 를 스캔하거나 하는 작업이 이루어 진다.
다음과 같은 시나리오를 생각해보자.
만약 동일한 물리적 CPU 안에서, worker thread가 작업을 수행 하다가 i/o 를 처리하기위해 대기 하고 있는데 이때 system thread가 수행되어 대용량 메모리 스캔을 위해 CPU를 할당하면 대용량 작업을 수행하기 때문에 공유된 L1&L2 캐시를 지워버린다. 다시 worker thread로 돌아와서 나머지 작업을 처리할려고 하니 이미 L1&L2 캐시에 없기 때문에 cache miss가 발생하고, 보조 기억장치인 RAM을 뒤지고, 여기에도 없다면 disk page i/o가 발생하게 된다.
이와같은 상황은 부하가 매우 높은 시스템에서라면 심각한 성능저하를 일으킬 수 있다.

또한 이런 시나리오는 SQL Server 환경이나, .NET, J2EE환경에서는 빈번하게 발생된다.
특히 SQL Server환경이라면, Lazy writer 뿐만아니라, worker thread 자체가 대용량 메모리를 스캔할수도있다(인덱스 부재로).

• 그럼 Hyper-Threading을 사용하지 말아야 하나?

그것은 아니다. 앞서 말한데로 Hyper-Threading 을 사용한 성능향상은 분명이 존재한다.
그리고 이것은 사용하고 있는 application 이나, 시스템 환경에 따라 달라진다.
또한 시나리오에 따른 성능저하 현상은 매우 높은 시스템 부하에서만이 확인해 볼수 있다.
따라서 우리 시스템에서 Hyper-Threading을 사용할지 말지는 그 시스템의 환경에 따라
충분한 테스트를 수행하고 나서 결정을 해야한다.

그것이 SQL Server라면, 메모리가 충분한지(lazy writer), 그리고 인덱스가 적절히 사용되어 대용량 메모리 스캔이 드물다면, 또한 heavy load가 아니면 개인적인 생각으로는 사용하는 것이 좋다고 판단한다.

이것에 관한 sql server 개발자의 의견은 많은 도움을 줄것이다..