아파치 httpd.conf 수정으로 성능 최적화

시스템 관리자란 어떤일을 하는가 서버가 ? 언제 어떻게 될지 모르는 상황에서 자기시간 이라는
개념이 없으며, 끊임없이 발생하는 취약성들에 대한 점검과 패치, 고객의 각종 문제들, 손실된
데이터 복구 문제 등 늘 긴장속에서 살아가야한다.
시스템 관리자라는 직업이 의미하는 바는 여기서 그치지 않는다.
시스템 유지보수, 성능 관리, 가용성 관리, 용량 관리, 장애 복구 등 시스템 관리자라면 대게 이
정도의 항목들을 관리하게 된다. 다른 분야 역시 마찬가지 이겠지만 시스템 관리자라는 업무는
끊임없는 자기 개발과 노력을 요구한다.
이 글에서는 시스템 관리자의 이런 개발과 노력에 도움이 되고자 리눅스로 운영하는 아파치
웹서버의 최적화에 관해서 다루기로 한다.
웹 서비스의 성능 최적화는 웹서버에서의 튜닝과 웹 브라우져, 웹 콘텐츠 그리고 다른
시스템과의 관계 등을 동시에 다루어야 하지만 자바스크립트, 웹 그래픽, HTML, CSS 등의
최적화에 대한 것은 이 글에서 취급하지 않는다. 필자는 http://www.websiteoptimization.com/
에서 그런 정보들을 얻을수 있었다.
이 글은 아파치 웹 서버의 최적화에 대해서만 다루고 있으므로, 그 외의 다른것들과 통합해서
웹 서비스 성능 개선 방안을 마련하는 것은 여러분의 몫이다.
2. 웹서버 성능측정방법
웹사이트가 느리면 고객은 바로 다른 사이트로 이동하기 마련이다.
따라서 기업은 고객을 확보, 유지하기 위해 웹사이트의 성능을 최상의 상태로 유지해야하며
이로 인해 웹사이트의 성능을 진단하고 분석하는 도구들에 대해서 많은 관심을 가지고 있으며
현재 기업들마다 다양한 방법들로 성능을 관리하고 있다.
웹서버의 성능을 측정하기 위해서 먼저 공개SW 벤치마크 프로그램 ab, Flood, Httperf 에
대해서 알아보기로 하자.

ab는 "Apache HTTP server Benchmarking tool" 의 약어로서 아파치서버의 응답속도를
측정하는 밴치마킹툴이다. 이 툴은 현재 설치된 아파치서버의 실행속도 및 성능테스트를
위해서 제우스테크널리지(Zeus Technology Ltd, http://www.zeustech.net/)의 Adam Twiss가
개발한 툴이며. 아파치를 설치하고 나면 기본적으로 설치되므로 별도의 설치 과정 없이 바로
사용할 수 있다.

Httperf
툴은 Httperf 요청이 발생하는 비율, 총 연결 수, 타임아웃 한계 등을 제어할 수 있다.
다운로드는 http://www.hpl.hp.com/research/linux/httperf/ 에서 가능하며 설치는 일반적인
소스설치법과 동일하게 ./configure ; make; make install 로 진행할수 있다.
사용할 수 있는 옵션은 아래와 같다
Server Software 아파치버전을 표시
Server Hostname 특정사이트의 이름(도메인명)
Server Port 웹서비스 사용포트번호
Document Path 초기 문서가 준재하는 웹문서 root위치
Time take for tests 응답시간(매우 중요한 결과 값임)
Document Length 초기문서(대부분 index.html, index.htm)의 용량크기
Complete requests 요구에 응답완료한 세션수
Failed requests 요구에 응답실패한 세션수
Broken pipe errors 실패한 에러수
Total transferred 총 전송바이트수
HTTP transferred 총 전송한 HTML바이트수
Requests per second 초당응답요구수
Time per request 요구에 응답한 시간(단위 micro second, 중요한 결과값)
Time per request 요구에 응답한 시간
Transfer rate 초당전송가능한 용량
--server 서버주소 여기에 적어 준 서버로 접속을 시도한다
--port 숫자 여기에 적어 준 포트로 접속을 시도한다
--num-conns 숫자 총 몇개의 접속을 만들 것인지를 결정한다.
--rate 숫자 초당 몇개의 접속을 만들 것인지를 결정한다.
--timeout 숫자 숫자만큼의 초 이후 응답이 없는 연결은 timeout 에러로 처리한다.
--think-timeout 숫자
CGI등 서버쪽에서 처리해야 하는 일들이 있는 페이지의 경우 서버측에
이를 처리할 시간을 준다. timeout에서 이곳에 주어진 숫자만큼을 더한
값이 진짜 timeout값이 된다.

5. 환경설정을 통한 성능 최적화
가. Timeout
접속된 클라이언트가 서버에 아무런 요청이 없을 때 어느정도 시간이 지나면 연결을 끊을지를
초단위로 설정한다 . 네트웍의 성능이 낮을수록 이 수치를 높게 설정하는 것이 좋다.
나. MaxClients
웹서버 성능에 가장 큰 영향을 주는 것은 메모리다. 방문자의 요청에 응답하기 위해서
프로세스가 생성되는되 이 지시자의 개수만큼만 생성가능하다. 여기서 지정한 개수 이상의
요청이 들어오면 아파치는 요청을 무시한다.
MaxClients 지시어를 조절하여 웹서버가 스왑을 할 정도로 많은 프로세스를 만들지 않도록
해야 한다. 스왑은 요청당 지연시간을 늘리기 때문에 웹서버는 스왑을 하면 안된다. top으로
프로세스 목록을 보고 아파치 프로세스의 평균 메모리 사용량을 알아낸후, 사용가능한
메모리의 양만큼 조절해준다
다. KeepAlive
아파치의 한 프로세스가 접속한 클라이언트의 지속적인 요청작업을 계속해서 처리하게 할
것인지를 결정하는 지시자. 이 지시자의 값을 On으로 되어 있어야 MaxKeepAliveRequests ,
KeepAliveTimeout 지시자가 유효하게 된다
라. MaxKeepAliveRequests
이전의 KeepAlive 지시어가 On 일때만 유효하다. KeepAlive 를 이용해서 한 프로세스가
접속한 클라인언트의 이어지는 요청을 모두 처리하도록 설정했는데, 이때 무한정 계속
처리하는것이 아니라 이 지시자를 이용해서 처리할 횟수를 지정해준다.
MaxKeepAliveRequests 100 처럼 설정해두면 프로세스가 100번의 요청을 처리한후 자신은
죽고 그다음 프로세스가 다시 클라인언트의 요청을 이어서 처리하도록 하는것이다. 방문자가
많은 홈페이지라면 이 값을 좀 올려두는것이 좋다
마. KeepAliveTimeout
이전의 KeepAlive 지시어가 On 일때만 유효하다. KeepAlive 를 사용한다면 프로세스들은 이미
열린 연결에서 추가 요청을 기다리며 대기중이다.
KeepAliveTimeout 15 처럼 설정해두면 클라이언트가 15초동안 아무요청이 없으면 프로세스의
연결을 끊는다. 이 값을 60 초 이상으로 올리면 사용자의 요청을 기다리며 아무일을 하지않는
- 10 -
프로세스가 60초동안 떠있게 되는것이다. 자신의 네트웍대역과 부하에 따라 적절히 조절하자.
기본값 15 로도 무방하다
바. StartServers
아파치 시작시에 실행시킬 프로세스의 개수. 뒤에나오는 MinSpareServers, MaxSpareServers
등의 지시자에 의해서 프로세스는 생성되기도 하고 죽기도 하므로 큰 의미를 가지는것은
아니다.
사. MinSpareServers
항상 대기하고 있을 프로세스의 최소개수. 여기서 지정한 숫자보다 적은 프로세스가 대기되어
있다면 아파치는 가능한 이 숫자를 유지하기위해 노력한다.
아. MaxSpareServers
항상 대기하고 있을 프로세스의 최대개수. 여기서 지정한 숫자보다 많은 프로세스가 대기되어
있다면 아파치는 가능한 이 숫자를 유지하기위해 노력한다.
자. MaxRequestsPerChild
하나의 프로세스당 최대 처리할 수 있는 방문자의 요청횟수
서버사양이 좋다면 이 값을 높여 두는것이 시스템의 부하조절과 자원낭비를 방지하는데 좋다.
차. HostnameLookups
웹서버의 로그(access_log)에 보면 클라이언트의 IP가 기록되어있는데 이 지시자를 On으로
설정하면 IP주소를 도메인명으로 기록하기위해서 노력을 하게된다.
아파치 1.3 이전에 HostnameLookups의 기본값은 On이였다.
이말은 접속을 요청하면 DNS를 검색해서 접속자의 호스트명을 알아내어야 한다는것이다,.
아파치 1.3에서 이 설정의 기본값이 Off로 변경되었다.
아파치의 성능을 생각한다면 반드시 Off 로 설정하기 바란다.
만일 로그파일의 주소를 호스트명으로 변환할 필요가 있다면 아파치에 포함된 logresolve
프로그램을 사용해서 나중에 할수있으니 실제 사용하는 웹서버가 아닌 다른 컴퓨터에서
로그파일을 후처리하길 바란다.