Apache -- Mpms & & Nginx 이벤트 드라이버

MPM 은 모두 다 중 처리 모듈 이 라 고 하 는데 우 리 는 apache 가 모듈 화 방식 으로 설계 되 었 다 는 것 을 안다.그 MPM 은 apache 가 사용자 의 요청 을 어떻게 처리 하 는 지 결정 하 는 데 사 용 됩 니 다.하나의 프로 세 스 를 통 해 요청 을 처리 하 는 것 입 니까? 아니면 하나의 스 레 드 로 요청 을 처리 하 는 것 입 니까?현재 MPM 에서 선택 할 수 있 는 세 가지 방법 이 있 습 니 다:

prefork

worker

event

상기 세 가지 방식 이 있 지만 어느 시간 에 든 하나 가 있어 야 하고 하나의 MPM 만 사용 할 수 있 습 니 다.다음은 이 세 가지 처리 방식 의 차 이 를 소개 한다.
prefork
이러한 작업 모델 에서 apache 프로 세 스 는 master 프로 세 스 와 worker 프로 세 스 로 나 뉜 다.웹 서비스 시작 은 master 프로 세 스 를 시작 하 는 것 입 니 다. 따라서 master 프로 세 스 는 몇 개의 worker 하위 프로 세 스 를 시작 합 니 다.master 프로 세 스 의 작업 은 워 커 하위 프로 세 스 를 관리 하 는 것 입 니 다.워 커 서브 프로 세 스 의 작업 은 사용자 요청 을 처리 하 는 것 입 니 다.사용자 가 요청 을 하면 apache 는 남 은 하위 프로 세 스 에서 이 사용자 의 요청 을 처리 하 는 것 을 선택 합 니 다.
이런 처리 방식 은 다음 과 같은 몇 가지 장점 이 있다.

사용 자 는 다른 프로 세 스 가 처 리 될 때 까지 기다 릴 필요 가 없습니다.남 은 하위 프로 세 스 만 있 으 면 새로운 요청 을 처리 할 수 있 기 때 문 입 니 다

워 커 서브 프로 세 스 가 무 너 지면 다른 워 커 프로 세 스 처리 요청 에 영향 을 주지 않 습 니 다.

그러나 워 커 서브 프로 세 스 의 개 수 는 apache 설정 파일 에서 다음 과 같은 몇 가지 항목 의 제한 으로 제 한 됩 니 다.

MinSpareServers 최소 남 은 worker 프로 세 스.

MaxSpareServers 최대 남 은 worker 프로 세 스 입 니 다. 이 수 를 초과 하면 일부 남 은 worker 프로 세 스 가 kill

MaxRequestWorkers 같은 시각 에 처리 할 수 있 는 요청 수, 즉 병발 량

MaxConnectionsPerChild 모든 워 커 서브 프로 세 스 가 평생 처리 할 수 있 는 요청 입 니 다. 이 수 를 초과 하면 master 프로 세 스 kill

또한, 일반 master 프로 세 스 는 루트 사용자 로 시작 하여 master 프로 세 스 가 80 포트 를 감청 하고 프로 세 스 를 관리 하 는 데 편리 합 니 다.나머지 워 커 서브 프로 세 스 는 apache 설정 파일 User 명령 으로 지정 한 사용자 로 시작 합 니 다.이 는 워 커 서브 프로 세 스 의 권한 을 줄 이 고 안전 을 보장 하기 위 한 것 입 니 다.

root@ff1221aa94a9:~# ps -aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   4448   676 ?        Ss   09:33   0:00 /bin/sh -c supervisord -n
root         5  0.0  0.8  60556 17172 ?        S    09:33   0:02 /usr/bin/python /usr/bin/supervisord -n
root        31  0.0  0.1  61384  3160 ?        Ss   09:33   0:00 /usr/sbin/sshd
root        32  0.0  0.8 200164 16384 ?        Ss   09:33   0:00 /usr/local/apache/bin/httpd -k start
daemon      33  0.0  0.4 200300  8392 ?        S    09:33   0:00 /usr/local/apache/bin/httpd -k start
daemon      34  0.0  03 200300  7512 ?        S    09:33   0:00 /usr/local/apache/bin/httpd -k start
daemon      35  0.0  0.3 200300  7512 ?        S    09:33   0:00 /usr/local/apache/bin/httpd -k start
daemon      36  0.0  0.3 200300  7512 ?        S    09:33   0:00 /usr/local/apache/bin/httpd -k start
daemon      37  0.0  0.3 200300  7512 ?        S    09:33   0:00 /usr/local/apache/bin/httpd -k start

ps 를 실행 하면 master 프로 세 스 만 루트 사용자 로 시작 하 는 것 을 볼 수 있 습 니 다.
worker
prefork 의 단점 은 매우 뚜렷 합 니 다. 하나의 worker 프로 세 스 가 요청 을 처리 하고 병행 이 높 지 않 으 며 프로 세 스 가 차지 하 는 자원 이 너무 많 습 니 다.하 는 일 은 부탁 하나 야.워 커 는 prefork 문 제 를 개선 했다.

마스터 부모 프로 세 스 가 여러 개의 키 프로 세 스 를 시작 합 니 다

각 하위 프로 세 스 가 몇 개의 스 레 드 를 시작 합 니 다

각 스 레 드 마다 요청 처리

이 경우 워 커 모델 의 동시성 은 prefork 모델 보다 높다.또한 스 레 드 의 씀 씀 이 가 프로 세 스 보다 작 기 때문에 워 커 모델 이 사용 하 는 자원 은 오히려 prefork 보다 작 습 니 다.
그러나 워 커 는 prefork 에 비해 비 스 레 드 안전 에 문제 가 있 습 니 다.가장 전형 적 인 문 제 는 apache 가 worker 모델 을 사용 하지만 phop 은 비 스 레 드 안전 버 전 을 사용 하면 이 두 가 지 는 일 을 할 수 없다 는 것 이다.그래서 워 커 가 아무리 좋아 도 비 스 레 드 보안 을 사용 하 는 역사 코드 를 만나면 prefork 모델 을 순 순 히 사용 할 수 밖 에 없습니다.
worker 모델 은 다 중 스 레 드 응답 요청 을 사용 합 니 다. 이 경우 하나의 스 레 드 가 충돌 하면 전체 프로 세 스 에 영향 을 줄 수 있 습 니 다.그래서 워 커 는 다 중 프로 세 스 + 다 중 스 레 드 혼합 모델 을 사용 합 니 다.동시성 을 높 일 수도 있 고 하나의 스 레 드 붕괴 로 인해 전체 웹 사이트 가 무 너 지 는 것 을 피 할 수도 있다.
prefork 와 마찬가지 로 worker 중성자 프로 세 스 와 스 레 드 수량 도 apache 설정 파일 의 통 제 를 받 습 니 다.다음 과 같은 인자 가 있 습 니 다.

MinSpareThreads 최소 빈 스 레 드

ThreadsPerChild 각 하위 프로 세 스 가 만 들 수 있 는 스 레 드 수량

MaxClients 동시에 처리 할 수 있 는 요청 수

。。。。。

그 웹 서 비 스 는 대체로 서버 설정 에 따라 이 매개 변 수 를 조절 하 는 것 이다.자세 한 매개 변 수 는 아파 치 문서 참조
Event
이벤트 모델 은 아파 치 2.2 이후 시험 특성 으로 도입 되 었 고 아파 치 2.4 이후 에 야 정식으로 지원 되 었 다.이벤트 모델 은 결 장 연결 (keep - alive) 문 제 를 이해 하기 위해 생 긴 것 이다.워 커 모델 을 사용 하면 하나의 스 레 드 가 하나의 요청 에 대응 합 니 다. 하나의 요청 이 긴 연결 일 때 스 레 드 는 긴 연결 상 태 를 유지 하고 클 라 이언 트 의 다음 요청 을 기다 립 니 다.이렇게 하면 현재 스 레 드 는 다른 클 라 이언 트 의 요청 을 처리 할 수 없습니다.
이벤트 모델 은 worker 모델 과 비슷 하고 여러 프로 세 스 + 여러 스 레 드 의 혼합 모델 입 니 다. 그러나 이벤트 모델 에서 모든 프로 세 스 는 하나의 단독 스 레 드 로 keep - alive 형식의 스 레 드 를 관리 합 니 다.새로운 요청 이 올 때 관리 스 레 드 는 다른 빈 스 레 드 에 요청 을 맡 깁 니 다.이렇게 하면 모든 라인 이 keep - alive 에 의 해 막 히 는 것 을 피 할 수 있다.
그러나 이벤트 모델 은 모든 상황 이 통용 되 는 것 이 아니 라 https 프로 토 콜 에서 워 커 모델 로 퇴화 합 니 다.구체 적 인 원인 은 공식 문 서 를 볼 수 있다.
Nginx
Apache 에 대해 서 는 현재 Nginx 를 언급 하지 않 을 수 없다.Apache 에 비해 Nginx 는 2004 년 에 정식 발표 되 었 고 Apache 는 1995 년 에 이미 나 타 났 다.당시 웹 환경 은 정적 페이지 를 간단하게 보 여 주 었 을 뿐 병발 량 이 지금 처럼 높 지 않 았 다.그래서 당시 아파 치 의 prefork 모델 도 웹 서비스 수 요 를 잘 감당 할 수 있 었 다.게다가 안정성 이 좋아 서 그것 을 쓰 지 않 을 이유 가 없다.
그 당시 에 인터넷 이 점점 커지 고 사이트 의 병발 량 이 커지 면서 Apache 에 C10K 문제 가 생 겼 다.즉, 하나의 물리 서버 가 병발 량 1W 에 이 르 렀 을 때 apache 는 감당 할 수 없다.이후 2004 년 Nginx 는 C10K 문 제 를 잘 해결 했다.Nginx 가 왜 apache 보다 낫 게 C10K 문 제 를 해결 할 수 있 는 지, 우 리 는 그 처리 요청 모델 부터 말 해 야 한다.
Nginx 는 세 가지 유명한 특성 이 있 습 니 다.

이벤트 구동 프로 그래 밍

비동기

비 IO 블록

바로 이 세 가지 프로 그래 밍 방식 이 Nginx 로 하여 금 이렇게 높 은 병발 량 을 가 질 수 있 게 한다.다음은 Nginx 가 어떻게 일 하 는 지 분석 해 보 겠 습 니 다.
마찬가지 로 Nginx 프로 세 스 도 master 프로 세 스 와 worker 하위 프로 세 스 로 나 뉜 다.(사실은 두 개의 cache 와 관련 된 프로 세 스 가 있 습 니 다. 여 기 는 생략 합 니 다)nginx 를 시작 하면 master 프로 세 스 는 일정 수량의 worker 서브 프로 세 스 를 만 들 고 그 후에 worker 서브 프로 세 스 의 수량 은 변 하지 않 습 니 다.그리고 이 worker 하위 프로 세 스 는 모두 단일 스 레 드 입 니 다.요청 이 왔 을 때 워 커 프로 세 스 의 한 남 은 프로 세 스 가 이 요청 을 처리 합 니 다.얼핏 보면 nginx 의 작업 모델 은 apache 와 별 차이 가 없다.관건 은 nginx 가 사용자 요청 을 어떻게 처리 하 느 냐 에 있다.
worker 하위 프로 세 스 가 처리 되 기 시 작 했 습 니 다. 이 요청 은 특정한 사이트 의 정적 페이지 를 방문 하 는 것 일 수 있 습 니 다.html 페이지 는 모두 하 드 디스크 에 저 장 됩 니 다.운영 체제 의 측면 에서 볼 때 nginx 는 하 드 디스크 의 파일 을 직접 읽 을 수 없습니다. nginx 가 운영 체제 에 어떤 파일 을 읽 어야 하 는 지 알려 준 다음 에 운영 체제 에서 이 파일 을 읽 고 읽 은 후에 운영 체제 에서 nginx 에 게 건 네 주어 야 합 니 다.즉, 운영 체제 에서 파일 을 읽 을 때 nginx 는 비어 있다 는 것 이다.apache 라면 이 럴 때 apache 의 worker 프로 세 스 / 스 레 드 가 막 혀 서 운영 체제 가 파일 을 읽 고 자신 에 게 제출 하 기 를 기다 리 고 있 습 니 다. 이것 을 IO 차단 이 라 고 합 니 다.
그러나 nginx 는 다 릅 니 다. nginx 의 worker 프로 세 스 는 이 럴 때 이 벤트 를 등록 합 니 다. 운영 체제 에 알려 주 는 것 과 같 습 니 다. 파일 을 다 읽 고 저 에 게 말씀 하 세 요. 제 가 먼저 다른 일 을 처리 하 겠 습 니 다.그리고 이 워 커 는 새로운 사용자 요청 을 처리 할 수 있 습 니 다.이 nginx 의 worker 프로 세 스 는 운영 체제 가 파일 을 읽 기 때문에 기다 리 는 것 을 막 지 않 았 습 니 다. 이것 을 비 IO 차단 이 라 고 합 니 다.
운영 체제 에서 파일 을 읽 은 후에 ngixn 에 게 알려 줍 니 다. 제 파일 이 읽 어 주 었 습 니 다. 가 져 가세 요."운영 체제 에서 파일 을 잘 읽 습 니 다" 라 는 이벤트 가 촉발 되 었 습 니 다. 그래서 Nginx 는 달 려 가서 파일 을 가 져 간 다음 응답 을 되 돌려 주 었 습 니 다.어떤 이벤트 가 발생 하여 Nginx 를 실행 시 키 는 방식 을 이벤트 구동 프로 그래 밍 이 라 고 합 니 다.
위 과정 을 돌 이 켜 보면 한 사용자 가 파일 을 읽 어 달라 고 요청 합 니 다. nginx 는 파일 을 읽 는 것 을 운영 체제 에 알 린 후에 다음 사용자 의 요청 을 처리 하고 운영 체제 가 파일 을 읽 은 후에 응답 을 되 돌려 줍 니 다.이 요청 은 처리 되 기도 전에 다음 요청 을 처리 하 는 프로 그래 밍 방식 인 비동기 프로 그래 밍 입 니 다.
바로 nginx 라 는 작업 모델 로 인해 nginx 는 일 정량의 worker 프로 세 스 를 유지 하면 서도 상당 한 병발 량 을 얻 을 수 있 습 니 다.이것 이 바로 nginx 가 apache 보다 좋 은 곳 입 니 다.마찬가지 로 nginx 의 이러한 요청 처리 모델 은 긴 연결 을 처리 할 때 도 사용 할 수 있 습 니 다.
Use Both
그렇다면 Nginx 가 Apache 보다 낫 고 Apache 가 알약 이 되 는 것 일 까?아니 야.후발 주자 의 등장 이 선배 가 잘 하 는 분야 에서 이기 지 않 았 다 면 후 자 는 전 자 를 완전히 대체 할 수 없 었 다 는 것 을 기억 해 야 한다.둘 이 병존 할 가능성 이 높다.nginx 자 체 는 php, python 등 스 크 립 트 언어 를 처리 할 수 없습니다. 이 동적 요청 을 CGI 를 통 해 다른 프로그램 에 전달 할 수 있 습 니 다.그래서 현재 일반적인 구 조 는 프론트 Ngixn 이 js, css, image 파일 과 같은 정적 파일 을 처리 하 는 것 입 니 다.요청 phop 등 동적 내용 에 부 딪 혔 습 니 다.백 엔 드 여러 apache 서버 에서 비교적 남 은 서버 를 선택 하여 이 요청 을 서버 에 전송 합 니 다.apache 가 처 리 된 후에 nginx 에 게 되 돌려 주 고 nginx 는 사용자 에 게 되 돌려 줍 니 다.이것 은 현재 전형 적 인 설계 방안 이다.위의 절차 에서 nginx 는 두 가지 기능 을 책임 집 니 다. 역방향 대리, 부하 균형 입 니 다.이것 도 nginx 가 잘 하 는 두 가지 기능 이다.한편, apache 의 풍부 한 모듈 은 한 사이트 의 각종 수 요 를 잘 만족 시 킬 수 있다.그리고 20 년 이상 의 시련 을 겪 었 기 때문에 아파 치 의 안정성 도 보장 할 수 있다.
웹 사이트 구조