ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Apache MPM
    STUDY/백엔드 2022. 1. 13. 01:27

     

    MPM(Multi Processing Module)은 다중 처리 모듈의 약자로, 클라이언트로부터 받은 요청을 어떤 방식으로 처리할 것인지에 대해 결정하는 모듈을 말한다.

    아파치에서 가장 대중적으로 사용하는 MPM에는 Prefork, Worker, Event 방식이 존재한다.

     

    Prefork

    • 미리 복수의 프로세스를 생성하여 클라이언트의 요청에 대비하는 멀티프로세스 방식이다.
    • 하나의 요청에 대해서 하나의 자식 프로세스가 하나의 스레드를 사용해서 처리하는 방식이다. 동시에 여러개의 요청이 들어올 경우, 미리 생성되어 있는 자식 프로세스에서 각 요청을 처리한다.
    • 각 프로세스들의 자원이 독립적이기 때문에(프로세스 복제시 메모리 영역까지 복제), 다른 요청이 들어오거나 프로세스 하나에 오류가 발생해도 다른 요청에 영향이 가지 않는다.
    • 하지만 프로세스가 많아질 경우, 메모리가 많이 소비된다.

     

    prefork 설정 예시

    설정

    • StartServers - 아파치가 실행될 때 생성하는 자식 프로세스 수 (default : 5)
    • MinSpareServers - 아파치가 유지하려는 최소 프로세스 수, 지정한 값보다 적을 경우 프로세스를 생성한다. (default : 5)
    • MaxSpareServers - 아파치가 유지하려는 최대 프로세스 수, 지정한 값보다 많을 경우 프로세스를 죽인다. (default : 10)
    • ServerLimit - 아파치가 생성 가능한 최대 프로세스 수
    • MaxClients - 동시에 접속할 수 있는 최대 client 수
    • MaxRequestsPerChild -  하나의 자식 프로세스가 받을 수 있는 최대 요청 개수, 지정한 값에 해당하는 요청을 처리 하면 프로세스를 자동으로 종료하고 부모 프로세스는 새로운 자식 프로세스를 준비한다. 0 으로 설정할 경우 무한대이다.

     

    Worker

    • 멀티쓰레드와 멀티프로세스의 하이브리드형 박식으로, 각 요청을 프로세스의 스레드로 받아 처리한다.
    • 연결마다 같은 메모리 공간을 공유하기 때문에 경합이 발생할 수 있고 이에 따른 주의가 필요하다.
    • 프로세스 별 스레드 개수 제한까지 요청을 받으며, 일정 개수가 넘어갈 때는 프로세스를 생성하여 처리한다.
    • prefork에 비해 메모리 등 리소스 사용량이 비교적 적다.
    • 하지만 프로세스 오류가 발생할 때 프로세스 내 스레드까지 죽어버리므로, 여러 연결이 동시에 끊어질 수 있다.
    • 통신량이 많은 대규모 환경에 적합하다.

     

    worker 설정 예시

    설정

    • StartServers : 아파치가 실행될 때 생성하는 자식 프로세스 수 (default : 3)
    • ServerLimit : 아파치가 생성 가능한 최대 프로세스 수(default : 16)
    • MaxReqeustWorkers : 최대 동시 접속자 수 (ServerLimit x ThreadsPerChild)
    • ThreadLimit : 자식프로세스의 라이프주기 동안 THreadsPerChild의 최대 설정값을 설정한다. (default : 64)
    • ThreadsPerChid : 프로세스당 가질 수 있는 스레드 수 (ThreadLimit 와 같은 의미, default : 64)
    • MinSpareThreads : 아파치가 유지할 최소 스레드 수 (default : 75)
    • MaxSpareThreads : 아파치가 유지할 최대 스레드 수 (default : 250)
    • MaxConnectionsPerChild : 하나의 자식 프로세스가 받을 수 있는 최대 요청 수, 지정한 값에 해당하는 요청을 처리 하면 프로세스를 자동으로 종료하고 부모 프로세스는 새로운 자식 프로세스를 준비한다. 0 으로 설정할 경우 무한대이다. 아파치 서버가 자주 다운되거나 메모리 문제가 발생한다면 이 값을 조절하여 해결할 수 있다.

     

     

     

     

    Event

    • Worker 방식을 기반으로 멀티쓰레드와 멀티프로세스로 동작한다. 클라이언트로부터 데이터를 기다리도록 유지되는 단점을 보완하기 위해 각 프로세스에 대한 전용 리스너 스레드를 사용하여 Listening 소켓, Keep Alive 상태에 있는 모든 소켓, 처리기 및 프로토콜 필터가 작업을 수행한 소켓 및 나머지 유일한 소켓을 처리한다.
    • 기존에는 클라이언트의 연결이 완전히 끝나지 않는 한 하나의 프로세스(또는 스레드)를 계속 연결하고 있었다.(리소스 부하) 따라서 대량 접속이 발생하는 경우 효율이 굉장히 떨어지는 이슈가 있었다.
    • Event Driven 지원 (한개 또는 고정된 프로세스만 생성하고 그 프로세스의 내부에서 비동기 방식으로 효율적으로 작업을 처리하는 방식으로, 속도가 가장 빠르다.)
    • 클라이언트 요청을 받는 스레드를 따로 두어, 분산된 처리를 한다.

     

    설정

    • StartServers : 아파치가 실행될 때 생성하는 자식 프로세스의 수 (default : 3)
    • ServerLimit : 아파치가 생성 가능한 최대 프로세스 수
    • MaxReqeustWorkers : 최대 동시 접속자 수 (ServerLimit x ThreadsPerChild)
    • MinSpareThreads : 아파치가 유지할 최소 스레드 수 (default : 75)
    • MaxSpareThreads : 아파치가 유지할 최대 스레드 수 (default : 250)
    • ThreadsPerChild : 프로세스당 가질 수 있는 스레드 수
    • MaxConnectionsPerChild : 자식 프로세스가 처리할 수 있는 최대 요청 수

     

     

    성능에 영향을 미치는 httpd.conf 설정

     

    1. Timeout

    지정한 시간동안 클라이언트가 응답이 없을 경우, 세션을 끊어 버린다.

    Timeout 60

     

    2. KeepAlive

    지속적인 연결을 허용 여부를 설정합니다. 비활성화하려면 Off 입력

    KeepAlive on

     

    3. MaxKeepAliveRequests

    허용할 최대 요청 수를 지정한다. 최상의 성능을 위해서는 수치를 높게 설정하는 것을 권장

    무제한으로 설정하려면 0으로 설정하면 된다.

    MaxKeepAliveRequests 100

     

    4. KeepAliveTimeout

    동일한 연결에서 동일한 클라이언트의 다음 요청을 대기하는 시간이다.

    응답이 없을 경우 서버가 클라이언트의 접속을 끊는다.

    KeepAliveTimeout 5

     

     

     

    참고

    https://blog.naver.com/PostView.nhn?blogId=skddms&logNo=221576799012

    https://blogger.pe.kr/921

    https://mcpaint.tistory.com/152

    https://junghyungil.tistory.com/118

    https://edu.goorm.io/learn/lecture/557/%ED%95%9C-%EB%88%88%EC%97%90-%EB%81%9D%EB%82%B4%EB%8A%94-node-js/lesson/21763/%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EA%B8%B0%EB%B0%98-%EB%B9%84%EB%8F%99%EA%B8%B0-%EB%B0%A9%EC%8B%9D

    'STUDY > 백엔드' 카테고리의 다른 글

    Spring Singleton vs Java static 기반 Singleton  (0) 2024.11.27
    실제 Client IP 구하기  (0) 2021.06.25
    Java Bean Validation  (0) 2021.05.07
    @Transactional  (0) 2021.05.07
    람다 표현식  (0) 2021.05.06
Designed by Tistory.