아파치 튜닝

아파치의 병렬처리와 MPM
병렬처리의 구현모델
- 프로세스를 여러 개 생성해서 병렬처리를 실현하는 멀티프로세스 모델
- 프로세스가 아니라 보다 경량의 실행단위인 쓰레드를 사용하는 멀티쓰레드 모델
- 입출력을 감시해서 이벤트가 발생하는 타이밍에 처리를 전환하는, 시그널 쓰레드로 병렬처리를 수행하는 이벤트 구동 모델

MPM(Multi Processing Module)
http://httpd.apache.org/docs/2.2/ko/mod/
prefork: 미리 복수의 프로세스를 생성해서 클라이언트의 접속에 대비하는 멀티프로세스 모델
<안전지향, 후방호환성이 높은 MPM>
worker: 멀티쓰레드와 멀티프로세스의 하이브리드형
<확장성이 높은 MPM>

- prefork를 worker로 변경하더라도 하나의 클라이언트에 대한 응답시간이 고속화되는 것은 아니다.
- prefork를 worker로 변경하더라도 메모리가 충분하다면 동시에 처리할 수 있는 접속 수는 변하지 않는다.
- prefork를 worker로 변경하더라도 대량의 컨텍스트 스위치가 없다면(동시에 병렬적으로 대량의 액세스가 없다면)효과는 크지 않다.

- 이용할 수 있는 메모리 용량이 그다ㅏ지 크지 않은 경우나, 메모리 소비량을 줄이고자 할 경우. 이런 경우, 프로세스보다 메모리 소비량이 적은 쓰레드의 이점이 살아난다.
- 컨텍스트 스위치 횟수가 많아서 그만큼의 CPU 리소스를 줄이고자 할 경우, 즉 대량의 액세스로 인한 CPU사용률을 줄이고자 할 경우. 프로세스보다 쓰레드 쪽이 컨택스트 스위치 비용은 낮으므로 CPU소비가 줄어든다.

httpd.conf 설정
아파치의 안전판 MaxClients

prefork의 경우
- ServerLimit: 서버 수 , 이를테면 prefork에서는 프로세스 수의 상한
- MaxClients: 동시에 접속할 수 있는 클라이언트 수의 상한
- MaxRequestsPerChild
카피온 라이트에 의한 메모리 공유는 시간의 경과에 따라 공유율이 하락해갔다. 이를 위해 아파치에서 정기적으로 자식 프로세스를 종료시키고 새로운 자식 프로세스를 생성시켜서 이 상태를 피해가는 방법이 있다.

worker의 경우
- 하나의 프로세스 내에 복수의 쓰레드를 생성하고, 쓰레드 하나로 클라이언트 하나를 처리한다.
- 해당 프로세스를 복수 개 생성한다.
- 쓰레드는 프로세스의 경우와 달리, 메모리 공간을 쓰레드끼리 완전히 공유한다. 카피온 라이트와 같은 경우를 생각할 필요가 없다.
- 하나의 쓰레드당 스택 영역으로 최대 8,192KB의 메모리를 필요로 한다.

MaxClients: 동시에 접속할 수 있는 클라이언트의 상한, 즉 프로세스 수 *쓰레드 수
ServerLimit: 프로세스 수의 상한
ThreadLimit: 프로세스당 쓰레드 수의 상한
ThreadsPerChid: 프로세스당 쓰레드 수

Keep-Alive

아파치 이외의 선택방안 검토
아파치의 장점:
내부가 깔끔하게 모듈화된 범용적인 구조로 되어 있어서 확장성이 높다는 점을 들 수 있다. 따라서, 써드파티를 포함한 확장모듈의 개발이 활발하다. 자신이 직접 새로운 모듈을 만들어서 아파치의 동작을 커스터마이징 하기도 한다.

lighttpd
- SPED(Single Process Event Driven)를 채용하고 있고, 적은 메모리로 대량의 접속을 동시병행적으로 처리하는 것을 주안에 둔 빠른 내부구현.
- 아파치에 비해 범용성은 뒤떨어지지만 그만큼 하나의 요청에 소요되는 계산량이 적기 때문에 CPU 소모가 적다.
- 싱글프로세스이므로 메모리 소비량이 아파치와 비교해서 훨씬 적게 든다.
- 아파치의 코어모듈, mod_rewite나 mod_proxy에 해당하는 기본적인 기능은 모두 포함하고 있다.
- FastCGI에도 대응하고 있고, 펄이나 PHP, Ruby로 작성한 웹 어플리케이션을 고속화해서 AP서버로 이용할 수 있다.

댓글

이 블로그의 인기 게시물

javascript ===, ==, >=, <=연산자

SQL oracle 내장함수[문자열 처리]

java 입출력2