아파치 튜닝
출처 : 불분명(통지바람)

1. 웹 페이지 로딩시간 확인
#time -pa lynx -source http://www.gwise.com > /dev/null
real 0.74
user 0.16
sys 0.09
-------------
실제 접속시간 : 0.74-(0.16+0.09)=0.49초

2. 아파치 벤치 마킹
#man ab 사용법 보기
-n requests 요청을 수행할 개수
-c concurrency 요청을 만들 개수로 동시 사용자 개념으로 이해하면 되겠다.
-v verbosity 얼마나 자세한 정보를 화면에 출력해 줄 것인지 결정
-w HTML 문서형식으로 테이블로 만들어 결과를 화면에 출력
-k HTTP 프로토콜의 지속연결 (KeepAlive) 기능을 사용

#./ab -n 100 -c 10 http://www.gwise.com:80/
10 명의 유저가 동시에 http://www.gwise.com/index.html 을 요청하는 것을 모의 실험.
각각의 시뮬레이트 유저는 요청을 10 번씩 하게 됩니다

# ab -n 1500 -c 50 http://www.apache.kr.net:80/
요청을 30 x 50 (50 명의 사용자가, 각각 30 번의 요청)

Requests per second: 80.48
초당 80.48개를 요청 했음.

'MaxRequestsPerChild’ 는 메모리 누수현상(?) 등이 발생하지 않는다면 가능한 이 값을 높게 설정하시고요(파라미터의 값을 0 으로 설정해 무한대로 하실수도 있습니다) StartServers’ 는 프로세스가 active 되어 있는 경우가 적을 경우 값을 낮게 설정하시고, 접속량이 아주 많을 경우는 MaxClients 에 가깝게 조절하시기 바라며, MaxSpareServers 를 MaxClients 와 같게 설정합니다. MaxClients 는 너무 낮게 설정하지 않도록 주의하시기 바라며, 그렇다고 또 너무 크게 잡으셔도 안됩니다


3. 웹 서버 삽질 막기
BrowserMatch "WebZip" go_out
BrowserMatch "Teleport" go_out
BrowserMatch "GetRight" go_out



....
Deny from env=go_out


4. 아파치 튜닝
일반 서버에서는 다른것은 그냥 Default 값으로 둔다.
(대형 서버의 경우 말고는 특히 쓸 일어 없을 것이다.)

증가 시킬 경우 배수로 한다. 꼭 이렇게 해야 한다가 아니라
이렇게 하면 좋다.

Timeout 300
클라이언트의 요청에 의해서 Server와 연결 되었을때
클라이언트와 서버간의 아무런 메시지가 발생하지 않았을때
오류로 처리하는 시간
네트워크 속도가 나쁠수록 수치값을 높게 한다.

KeepAlive on
지속적인 접속, 즉 서버 연결에 대하여 한번 이상의 요청을 허용 여부.

MaxKeepAliveRequests 100
클라이언트가 접속된 시간동안 아파치 서버에 요청할 수 있는 처리 process 개수

StartServers 5 X ? =20 -> 초반에 뜰 process 그 이상 그이하의 의미도 없다.
MinSpareServers 5 X ? =20 -> Spare 프로세스가 이것 이하 일때 끌어 올려 준다.
MaxSpareServers 10 X ? =40 -> Spare 프로세스가 이것 이상 일때 진정(?)시켜 준다.
말 그대로 Spare.... 언제 있을지 모를 요청에 대해서 컴퓨터 스스로가
조절해 준다.

MaxClients 150
클라이언트들이 동시에 최대로 접속했을때 가능한 최대 서버이 수를 지정.
Ulimit -a ~~~ max process...이 수치 이상 증가 못함.
httpd.h
HARD_SERVER_LIMIT=250 조정해서 다시 컴파일 가능

MaxClient 150 -> 동시에 떠 있을수 있는 최대 process
더 많은 수를 원할시 httpd.h 소스 파일의
HARD_SERVER_LIMIT 값을 수정 한 다음 다시 컴파일 해야 한다.

#ulimit -a
core file size (blocks) 0
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 2048
pipe size (512 bytes) 8
open files 1024
virtual memory (kbytes) 2105343
-----------------------
위의 max user processes 의 수를 초과 할 수 없다.

MaxRequestPerChild 100
한 프로세스가 몇 번의 서비스를 하고 소멸될 것인지 정한다.
M$계열에서는 별 의미가 없으므로 0을 한다.
하지만 Unix 계열은 0을 사용하지 않는 것이 좋다.

가장 중요한 것은Timeout 설정입니다. 위에서 keep-alive 를 설정해 놓은
경우, 하나의 connection에서 계속해서 다음 request를 처리할 수 있기 때문에 효율적
이라고 하지만, 실제로는 그렇지 않습니다. keep-alive 를 허용하고 그 timeout을
5초로만 설정해도, 하나의 request를 처리한 후 적어도 5초동안은 그 httpd가 다른
작업을 하지 못하고 다음 request를 기다리게 됩니다.

보통 웹브라우저들은 서버로 동시에 4개의 connection을 만들게 됩니다. 한 페이지를
보는데 이미지 등등 해서 보통 4개의 connection을 만드는 것은 기본이죠. 이렇게 되면
httpd가 100개 떠 있다고 해도, 실제로는 동시에 25명의 방문자밖에 처리하지 못합니다.

그리고 keep-alive timeout이 5초인 경우, 한 명의 방문자를 처리한 후 적어도 5초동안은
계속해서 기다리면서 httpd가 놀게 됩니다.(그렇다고 해서 httpd의 수를 늘여주면 앞의
문제 때문에 load가 몰릴 때 순간적으로 부하가 지나치게 많이 걸리게 됩니다. 어떤
request는 수초가 지난 후 답을 받는 등 quality of service가 많이 떨어지죠.)

결국 한 명의 방문자를 처리하는데 4개의 httpd가 5초동안 작업한다는 뜻이고, 100개의
httpd를 띄워봐야 1초에 5명의 방문자밖에 처리하지 못하는 셈입니다. ( 1 명 / 5 sec /
4 httpd = 5 / 1 sec / 100 httpd )

그래서 검색엔진 서비스 등 traffic이 많은 사이트에서는 keep-alive 옵션을 반드시 꺼
놓게 됩니다. 그리고 connection timeout도 상당히 짧게 설정해 놓죠. 4~5초 이내로 말입니다

http://www.apache.org/docs/misc/perf-tuning.html
web performance tunning - 오렐리

그렇지만 명심할 점이 있습니다. 웹사이트의 성능 개선을 위해서는 커널에서만
손대주는 것이 아니라 OS, 네트웍, 프로그래밍 등 다양한 조건을 같이 고려해야
한다는 것입니다. 또한 하드웨어 성능을 고려하지 않은채 무작정 바꾸면 문제가
생긴다는 것입니다. 또한 일반적으로 정적인 html서비스는 문제가 안되지만 성능의
병목지점이 생기는 곳은 네트웍이 아니라면 cgi일 경우가 많습니다. 아파치에
들어있는 ab, 유닉스의 time, ping, netstat 등 다양한 명령어들을 이용해서 항상
시스템의 상태를 모니터링해보고 속도를 재어 보아야 합니다. 또한 아무리 튜닝을
잘해도 웹페이지에 이미지를 엄청나게 넣어둔다면 헛일하는것이지요. 저도 잘
모르면서 어설크게 오라클 튜닝을 한다고 했더니 cpu 4개, 메모리 2G인 시스템에서
오히려 일반PC보다 오라클이 더 느려지더군요. 잘 모르는 경우에는 기본값을 사용하는
것이 더 나을때도 있지요. 아래 예에서 keepalive 옵션은 대형 사이트같은 경우에는
off로 해 놓는 것이 더 나은 경우도 많이 있습니다. 빨리 처리하고 연결을 빨리빨리
끊어주는 것이 아무일도 하지 않은채 그냥 프로세스를 띄워놓고 놀리는 것보다는
낫지요.




아파치 웹 서버 튜닝
문태준(taejun at tunelinux.pe.kr http://tunelinux.pe.kr)

아파치 웹 서버의 튜닝은 간략하게 두 부분으로 나눌 수 있다. 첫 번째는 소스코드에
하드코딩 되어 있는 제한 값을 조정하는 것이고, 두 번째는 환경설정 파일의 각 제한
값들을 수정하는 것이다.

1) 소스레벨
httpd.h 파일에 리눅스의 경우 HARD_SERVER_LIMIT 값이 256으로 기본 설정되어
있으며, 이 값은 서버가 수용할 수 있는 최대 접속을 의미한다. 이 값을 1280으로
설정한다.

2) 환경설정 파일
가. KeepAliveTimeout
클라이언트가 서버로 접속을 했을 경우 하나의 웹 서버 프로세스가 해당 웹 페이지의
여러 개체들의 전송을 새로운 프로세스를 생성하지 않고 지속적으로 접속을 유지하며
담당하며, 이 클라이언트의 요청에 대한 타임아웃에 대한 값이다. 기본 15초에서
30초로 증가.
나. MaxKeepAliveRequests
웹 서버 프로세스가 지속적으로 접속을 유지하면서 처리할 수 있는 요청 개수이다.
100으로 설정되어 있으며, 10000으로 증가.
다. StartServer, Min/MaxSpareServer
기본 설정은 5, 5, 10정도이며, 웹 서버가 Standalone 방식일 경우 새로운 접속
요청을 받으면 기존의 Spare Child Process를 포크하여 새로운 Child Process를
만들어내므로 기본적으로 Spare Process가 많을수록 폭주에 빨리 대처할 수 있다.
StartServer 20, MinSpareServer 20, MaxSpareServer 40으로 증가.
라. MaxRequestsPerChild
웹 서버 프로세스가 일정 횟수의 클라이언트 요청을 처리하고 종료되는 수치이며,
1000으로 증가.
마. MaxClients
동시에 실행될 수 있는 최대 프로세스 수를 제한하는 것이며, 기본 256으로 설정되어
있다. 이를 512까지 증가.
바. 로그파일 생성
이용자가 접속할 때마다 기록되는 access_log 파일의 경우 한번 접속당 약 85바이트가
증가하며, 접속량이 많을 경우 이 파일의 크기는 실제로 엄청나다. 이럴 경우
접속때마다 로그파일을 액세스하는데 상당한 시간과 부하가 걸리므로 로그 파일을
일정시간마다 초기화하여 항상 경량화 시켜 줄 필요가 있다. 아파치에서 제공하는
rotatelog를 이용.


ㅇ커널 소프트 레벨 튜닝

커널이 제공하는 파라메터값을 /proc 파일 시스템을 이용해서 부팅이 완료된 시점후에
변경한다. 여기서는 주로 파일시스템과 네트웍 자원에 관련된 내용에 대해서
튜닝한다.

1) 파일 시스템 관련
- 리눅스 커널이 할당할 수 있는 파일 개수의 최대값 : 4096 -> 32768
- 리눅스 커널이 할당할 수 있는 inode 개수의 최대값 : 16384 -> 65536
- root 사용자에 대해 할당할 수 있는 파일 개수의 최대값 : 1024 -> 32768
- 하나의 프로세스가 오픈할 수 있는 파일의 개수 : 256 -> 512

2) 네트웍 자원 관련
- TCP 가 Keep Alive 메시지를 보내는 시간 간격 : 7200 -> 1200
- 소켓이 항상 CLOSE되기 전에 마지막 FIN 을 기다리는 시간 : 180 -> 30
- 하나의 TCP 접속 요청에 대해 응답을 재전송하는 횟수 : 7 -> 2

이렇게 설정되는 값들은 시스템이 부팅되면서 스크립트를 통해 설정되어야 되기
때문에 /etc/rc.d/rc.local 파일의 마지막 부분에 정의된다.

ㅇ 커널 하드 레벨 튜닝

커널 소스를 직접 수정하여 제한값을 조정한다. 이를 위해서는 커널 컴파일이
필수적이며, 조심스런 접근이 필요하다.

- 파일 오픈 개수
- 처리할 수 있는 프로세스 개수

**참고

1. 아파치 웹 서버 튜닝
- apache/src/include/httpd.h:
HARD_SERVER_LIMIT 256 -> 1280
- apache/conf/httpd.conf:
MaxKeepAliveRequests 100 -> 10000
KeepAliveTimeout 15 -> 30
MinSpareServers 5 -> 20
MaxSpareServers 10 -> 40
StartServers 5 -> 20
MaxClients 256 -> 1024

2. 커널 소프트 레벨 튜닝
- ulimit -n 32768
- /proc/sys/fs/file-max: 4096 -> 32768
- /proc/sys/fs/inode-max: 16384 -> 65536
- /proc/sys/net/ipv4/tcp_keepalive_time: 7200 -> 1200
- /proc/sys/net/ipv4/tcp_fin_timeout: 180 -> 30
- /proc/sys/net/ipv4/tcp_sack: 1 -> 0
- /proc/sys/net/ipv4/tcp_timestamps: 1 -> 0
- /proc/sys/net/ipv4/tcp_syncookies: 0 -> 1
- /proc/sys/net/ipv4/tcp_retries1: 7 -> 2
- /proc/sys/net/ipv4/tcp_max_syn_backlog: 128 -> 8192
- /proc/sys/net/ipv4/tcp_window_scaling: 1-> 0

3. 커널 하드 레벨 튜닝
- /usr/src/linux/include/linux/fs.h:
NR_FILE 4096 -> 32768
INR_OPEN 1024 -> 32767
- /usr/src/linux/include/linux/tasks.h:
NR_TASKS 2560 -> 3192
MAX_TASKS_PER_USER 2048 -> 3192
- /usr/src/linux/include/linux/limits.h:
NR_OPEN 1024 -> 32767
- /usr/src/linux/include/net/tcp.h:
TCP_TIMEWAIT_LEN (60*HZ) -> (15*HZ)



출처 : http://blog.paran.com/coacoma/4378933