 |
|
|
 |
|
|
- 1. 개요
웹 서비스의 성능 최적화는 흔히 서버측에서만의 튜닝을 생각하기 쉬운데 사실, 정확한 의미의 성능 최적화는 웹 서비스 이용자와 서버측 모두의 성능 개선에 있다.
그러나 이 문서에서는 서버측의 성능 개선에 대해서만 언급한다.
2. 기본적인 성능 개선 방안
(1) 더 빠른 인터넷 전용선을 확보한다.
- 성능을 개선할수 있는 가장 확실한 선택은 바로 더 빠른 전용선을 확보하는 것이다. 그러나 비용면에서 월 유지비가 많이 들어 가급적 사용량에 따라 최적의
전용선 속도를 선택하는 것이 현명하다.
MRTG에서 자사의 인터넷 사용량(IN/OUT)이 전용선 속도의 80% 이상까지 다다르면 패킷 손실이 생겨 폭주 및 과부하가 자주 발생할수 있으므로, 전용선 업
그레이드를 고려할 필요가 있다.
(2) 최적의 Subnet Mask를 설정한다.
- 라우터의 경우 불필요한 Subnet Mask를 줄여줄 필요가 있다. 가령 같은 라우터에 연결된 컴퓨터들의 IP address 갯수가 30개밖에 되지 않으면서 굳이
subnetmask를 255.255.255.0로 잡아 사용하게 되면 나머지 225개의 D class IP address를 검색하느라 라우팅 속도가 느려질 수 있다.
(3) 웹 서비스만을 위한 단독 시스템을 확보한다.
- 웹 서버와 메일 서버, 그리고 DNS 서버에 이르기까지 하나의 시스템으로 사용하는 경우가 많은데 이것은 웹 서비스로는 치명적이다. 보안 문제가 생길 수도
있으며 웹서버의 부하에 의해 다른 서비스에 차질이 생길 수 있다. 가급적이면 웹 서버 시스템을 따로 구성하는데, 웹 서버 시스템의 경우 보통 RAM 용량을 충분
히 확보해야 한다.
(4) 운영체제의 각종 제한 수치를 조정한다.
- Linux의 경우 Sun과 같이 대용량 시스템이 아닌 PC급 서버를 기본 플렛폼으로 개발되고 서비스되는 까닭에 OS의 기본 설정이 Solaris에 비해 낮게 설정되어 있
다.
결국 Linux에서 과부하를 이겨내기 위해서는 Linux 커널의 수정이 불가피하다.
그리고 운영체제에서의 TCP 재전송 최대 대기 시간 (TCP retransmit timeout)을 증가시킬 필요가 있다.
보통200 msec로 잡혀 있는데 느린 인터넷 환경에서는 200msec의 경우 TCP의 재전송 최대 대기 시간으론 부족할 수 있다.
이 외에도 웹 서버의 성능을 위해 각종 프로세스 관련 제한 수치를 조정할 필요가 있다.
(5) 웹 서버 프로그램의 성능을 최적화 한다.
- 웹 서버의 config 파일등에서 성능 향상을 위한 적절한 설정이 필요하다.
(6) 자주 사용되는 cgi 결과들은 FILE(HTML…) 로 만든다.
- 이용자가 자주 실행하는 CGI 프로그램에 대한 결과나 DB 검색 결과등은 주기적으로 File(HTML…)로 만들 필요가 있다.
실행할 때마다 DB connect 에 의한 부하등을 획기적으로 줄일수 있기 때문이다.
현재 대부분의 검색 사이트들은 위와 같이 자주 읽히는 검색 결과들을 crontab을 이용하여 주기적으로 File로 만들어 두고 있다.
(7) 웹 서버를 분산 시킬 필요가 있다.
- 그래도 과부하에 의해 서비스가 지연될 경우에는 부하가 많이 걸리는 웹 사이트들을 따로 분리할 필요가 있다.
또는 DNS에서의 Round Robin 설정을 통해 이용자가nslookup할때마다 다수의 IP 주소를 순차적으로 보내어 같은 웹 페이지를 가진 여러대의 웹 서버로 접속을 분
산하면 그만큼 부하가 줄어들 것이다.
이외에도 전문 로드밸런싱 소프트웨어를 이용하면 웹 서버의 접속 분산에 있어서 보다 지능화된 연결이 가능하다.
3. 아파치 웹 서버의 성능 개선 방법
- httpd.conf , srm.conf , access.conf 파일의 최적화 수정
예전에는 httpd.conf, srm.conf, access.conf 파일로 나누어져 있었지만 요즘의 아파치 웹 서버는 모든 config 관련 내용이 httpd.conf에 들어가 있다.
- ServerType : StandAlone
이것은 이용자 접속 요청 시 웹 서버의 Child Processor의 생성에 있어서 기존 Spare Child Processor를 복사(Fork)하여 빠르게 대쳐할수 있도록 한다.
가령 100명의 이용자가 동시에 웹 서버로 접속할 경우 그때마다 config 파일을 참고로 하여 새로운 Child Processor가 만들어지는 inetd 방식보다 기존의 여유
Child processor를 fork 하여 대응하는 것이 훨씬 빠르고 효율적이다.
- HostNameLookup off
이것은 접속자의 IP 주소에 대한 Reverse Lookup 을 방지한다.
대부분의 이용자들은 자신의 IP 주소에 대한 호스트, 도메인 이름이 없다.
그러므로 만일 HostNameLookup on 을 하여 웹 서버가 매번 접속 요청자에 대한 네임 서버 검색 후 로그 파일을 작성하도록 하면 그 만큼 접속 시간과 부하량이 증
가하게 된다.
- Rotate log를 사용한다.
이용자가 접속할때마다 기록되는 access_log의 경우 한 번 접속당 약 85Byte가 증가하여 하루 100만번의 접속으로 access_log 파일은 무려 약 405MByte가 증가
한다.
이렇게 되면 접속때마다 log file을 access 하는데 상당한 시간과 부하가 발생된다.
그러므로 로그 파일을 일정 시간마다 초기화 함으로서 언제나 경량화 시켜줄 필요가 있는데, 이것은 httpd/support 디렉토리에 존재하는 rotatelogs라는 유틸리티
를 쓰면 해결할 수 있다.
레드햇 리눅스 5.2 이상의 경우 syslog을 이용하여 log 파일을 관리하고 있다.
[ 형 식 : rotatelog logfilename time ]
httpd.conf의 TransferLog logs/access_log를 아래와 같이 수정
TransferLog “|/usr/loca/etc/httpd/support/rotatelogs /usr/local/etc/httpd/logs/access_log 86400”
## 86,400초 (24시간)마다 access_log을 갱신한다는 뜻
참고 : error log 역시 위와같은 방법으로 수정 가능
- ServerAlias를 이용한다.
가상 호스팅 추가시 ServerName www.domain.com 외에 ServerAlias *.domain.com domain.com 를 아래에 추가하여 Alias 도메인의 가상 호스팅을 위해 불필요
한 필드의 추가를 생략할 수 있다.
- Error_log파일을 통합한다.
가상 호스팅의 경우 가급적 error_log 파일들은 하나의 error_log 파일로 지정해 관리한다.
- KeepAlive on
이것은 접속 요청자에게 웹 서버 프로세스가 웹 페이지들을 전송할 때 내부의 여러 개체(그림파일) 전송까지 새로운 프로세스를 만들지 않고 담당 프로세스가 계속
접속을 유지 할 수 있도록 한다.
- MaxRequestPerChild 를 증가시킨다.
프로세스가 일정 횟수의 클라이언트 요청을 처리하고 종료되는 추치인 MaxRequestPerChild 30을 시스템의 안정성에 따라 증가시켜준다.
보통 100 이상을 권한다. 만일 자신의 웹 서버 시스템이 상당히 안정적이라면 아예 1,000을 주기도한다.
- StartServer, Min, Max Spare Server 수를 가급적 증가시켜준다.
디폴트는 각각 5, 5, 10정도인데 웹 서버가 standalone 방식을 경우 새로운 접속 요청을 받으면 기존의 spare Child Processor를 Fork 하여 새로운 Child Process
or를 만들어 내므로 기본적으로 Spare 프로세스가 많을 수록 폭주에 빨리 대처할 수 있다.
각각 비례적으로 증가시키는 것이 바람직하다.
예) StartServer 20, Min SpareServer 20, Max SpareServer 40 (4배씩 증가)
- MaxClient 150
이것은 동시에 떠 있을수 있는 최대 Processor 수를 제한하는 것인데, 이것은 결국최대 동시 이용자수 제한과 같다.
물론, http 프로토콜의 특성상 접속자체가 비연결성을 가지므로, 150정도가 충분할수 있으나 필요 시 더 늘려줄수도 있다.
그러나 OS에서의 기본 제한 수치를 넘어설 수 있으므로, 주의 해야 한다.
가령 nobody가 만들어낼수 있는 최대 프로세스의 개수가 150개로 OS에서 제한하고 있는데 MaxClient를 그 이상으로 조정하면 문제가 생길 수 있다.
4. 운영체제(OS)의 각종 제한 설정 확인
앞서 언급한 각 Processor 수치와 가상 호스팅을 위한 동시에 Open되는 Log 파일의 개수를 확장하기 위해서는 해당 웹 서버의 운영체제의 자원에 대한 제한 수치
를 확인할 필요가 있다.
ulimit
ulimit은 운영체제의 각종 Limit을 확인하는 명령어로서 아래의 수치를 확인할 수 있다.
The Max number of system processess
The Max number of processes per user
The Max number of open files (can have open files)
웹 서버는 보통 nobody라는 이용자 권한을 가진 ChildProcessor에 의해 서비스된다.
가령 레드햇 리눅스의 경우 6.0 버전 이상부터 그 기본 수치가 상당히 증가되었는데, 이전 5.2버전의 경우 ulimit ?a 으로 아래의 결과를 보인다.
[root@ns named]# ulimit -a
core file size (blocks) 1000000
data seg size (kbytes) unlimited
file size (blocks) unlimited
max memory size (kbytes) unlimited
stack size (kbytes) 8192
cpu time (seconds) unlimited
max user processes 256
pipe size (512 bytes) 8
open files 256
virtual memory (kbytes) 2105343
여기서 max user processes가 256 정도인데, 아파치 웹 서버의 conf 파일에서 MaxClient 를 256 이상 설정하면 OS의 기본 설정을 초과하므로 문제가 발생할
수있다.
OpenFiles 역시 256이므로, access_log, error_log를 각 가상 호스팅 이용자에게 따로 부여할 경우에는 웹 서버의 log 파일의 총 개수가 256보다 아래여야 할것
이다.
물론이용자가 cgi 프로그램을 동시에 실행하여 open되는 file수도 고려해야 한다.
참고로 ulimit는 OS의 기본 설정을 확인하거나 기본 수치에 대해 줄일 때 사용할 수 있다.
그러므로 ulimit을 통해 각 분야별 수치를 증가시키는 것은 아무런 효과가 없다.
OS의 기본 제한 수치를 증가시키고자 한다면 리눅스의 경우 별도의 커널 수정과 커널 컴파일이 필요하다.
그러나 레드헷 6.0부터 커널의 각종 설정들이 상당히 증가되어(예 : openfiles, max user processes 가 1024로 증가) 이젠 굳이 커널을 수정하여 컴파일할 필요가
없다.
|
|
|
|
|
