nginx가 왜 그렇게 빠른가요?

우리 모두는 nginx가 고성능, 안정성, 풍부한 기능, 간단한 구성 및 낮은 리소스 소비로 유명하다는 것을 알고 있는데 nginx가 왜 그렇게 빠른가요? 기본 원리부터 분석해 보겠습니다.

Nginx 프로세스 모델

Nginx 서버, 정상 작동 중:

다중 프로세스: 하나의 마스터 프로세스와 여러 작업자 프로세스.

Master 프로세스: Worker 프로세스를 관리합니다.

외부 인터페이스: 외부 작업(신호) 수신

내부 전달: 다양한 외부 작업에 따른 신호를 통해 작업자 관리

모니터링: 작업자 프로세스의 실행 상태를 모니터링하고 작업자 프로세스가 비정상적으로 종료되면 자동으로 다시 시작 프로세스.

Worker 프로세스: 모든 Worker 프로세스는 동일합니다.

실제 처리: 작업자 프로세스에 의해 처리되는 네트워크 요청입니다.

작업자 프로세스 수: nginx.conf에 구성되며 일반적으로 CPU 리소스를 최대한 활용하기 위한 코어 수로 설정됩니다. 동시에 과도한 프로세스 수를 피하고 프로세스가 CPU 리소스를 두고 경쟁하는 것을 피하고 손실을 늘리세요. 컨텍스트 스위칭의.

생각하기:

요청이 Nginx에 연결되어 있고 마스터 프로세스가 처리와 전달을 담당한다고요?

요청을 처리할 작업자 프로세스를 선택하는 방법은 무엇입니까?

요청 처리 결과도 마스터 과정을 거쳐야 하나요?

HTTP 연결 설정 및 요청 처리 과정은 다음과 같습니다.

Nginx가 시작되면 마스터 프로세스가 구성 파일을 로드합니다. 마스터 프로세스는 청취 소켓을 초기화합니다. 마스터 프로세스, 여러 작업자 프로세스를 분기합니다. 작업자 프로세스는 새로운 연결을 위해 경쟁합니다. 승자는 3방향 핸드셰이크를 통해 소켓 연결을 설정하고 요청을 처리합니다.

Nginx 고성능, 높은 동시성

왜 Nginx는 고성능이고 높은 동시성을 지원할 수 있나요?

Nginx는 다중 프로세스 + 비동기 비차단 방식(IO 다중화 Epoll)을 채택합니다. 요청의 전체 프로세스: 링크 설정 → 요청 읽기 → 요청 구문 분석 → 요청 처리 → 요청에 응답합니다. 요청의 전체 프로세스는 소켓 이벤트 읽기 및 쓰기라는 맨 아래 계층에 해당합니다.

Nginx 이벤트 처리 모델

요청: Nginx의 HTTP 요청입니다.

기본 HTTP 웹 서버 작동 모드:

요청 수신: 요청 라인과 요청 헤더를 한 줄씩 읽고 세그먼트에 요청 본문이 있다고 판단한 후 요청 본문을 읽습니다. 요청을 처리합니다. 응답 반환: 처리 결과에 따라 해당 HTTP 요청(응답 줄, 응답 헤더, 응답 본문)을 생성합니다.

Nginx도 이 루틴을 따르며 전체 프로세스는 동일합니다.

모듈형 아키텍처

Nginx 모듈은 기본적으로 기능에 따라 다음과 같은 유형으로 나눌 수 있습니다. 독립 운영 체제의 이벤트 처리 메커니즘의 프레임워크이며 특정 이벤트의 처리를 제공합니다. ngx_events_module, ngx_event_core_module 및 ngx_epoll_module 등을 포함합니다.

Nginx에서 사용하는 특정 이벤트 처리 모듈은 특정 운영 체제 및 컴파일 옵션에 따라 다릅니다.

②Phase 핸들러: 이 유형의 모듈을 핸들러 모듈이라고도 합니다. 클라이언트 정적 페이지 요청을 처리하고 응답 콘텐츠 출력을 위해 해당 디스크 파일을 준비하는 ngx_http_static_module 모듈과 같이 클라이언트 요청을 처리하고 응답할 콘텐츠를 생성하는 일을 주로 담당합니다.

3출력 필터: 필터 모듈이라고도 하며 주로 출력 내용 처리를 담당하며 출력을 수정할 수 있습니다.

예를 들어 모든 출력 HTML 페이지에 미리 정의된 풋바를 추가하거나 출력 이미지의 URL을 바꿀 수 있습니다.

4upstream: 업스트림 모듈은 역방향 프록시 기능을 구현하고, 실제 요청을 백엔드 서버로 전달하고, 백엔드 서버의 응답을 읽어 클라이언트로 다시 보냅니다.

업스트림 모듈은 응답 콘텐츠가 실제로 자체적으로 생성되지 않고 백엔드 서버에서 읽힌다는 점을 제외하면 특수 핸들러입니다.

⑤로드 밸런서: 로드 밸런싱 모듈은 특정 알고리즘을 구현하고 여러 백엔드 서버 중에서 특정 요청에 대한 전달 서버로 서버를 선택합니다.

일반적인 문제 분석:

Nginx 대 Apache

Nginx:

IO 멀티플렉싱, Epoll(freebsd의 kqueue), 고성능 및 높은 동시성, 적은 시스템 리소스 차지

Apache:

차단 + 다중 프로세스/ 다중 스레드가 더 안정적이고 버그가 적으며 모듈이 더 풍부합니다

Nginx 최대 연결 수

기본 배경:

Nginx는 다중 프로세스 모델이며 작업자 프로세스는 요청을 처리하는 데 사용됩니다. 단일 프로세스의 연결 수(파일 설명자 fd)에는 상한(nofile)이 있습니다: ulimit -n. Nginx에서 단일 작업자 프로세스에 대한 최대 연결 수를 구성합니다. 작업자_연결의 상한은 nofile입니다. Nginx에서 작업자 프로세스 수(worker_processes)를 구성합니다.

따라서 Nginx의 최대 연결 수:

Nginx의 최대 연결 수: 작업자 프로세스 수 x 단일 작업자 프로세스의 최대 연결 수입니다. 위 내용은 Nginx를 일반 서버로 사용할 경우의 최대 연결 수입니다. Nginx가 역방향 프록시 서버로 작동할 때 제공할 수 있는 최대 연결 수: (작업자 프로세스 수 x 단일 작업자 프로세스의 최대 연결 수) / 2. Nginx 리버스 프록시를 사용하면 클라이언트에 대한 연결과 백엔드 웹 서버에 대한 연결이 설정되어 2개의 연결을 차지합니다.

생각하기:

소켓이 열릴 때마다 fd를 차지한다고요? 프로세스가 열 수 있는 fd 수에 제한이 있는 이유는 무엇입니까?

HTTP 요청 및 응답

HTTP 요청:

요청 줄: 메서드, uri, http 버전 요청 헤더 요청 본문

HTTP 응답:

응답 줄: http 버전, 상태 코드 응답 헤더 응답 본문

IO 모델

여러 요청을 처리할 때 다음을 사용할 수 있습니다. IO 멀티플렉싱 또는 차단 IO + 멀티 스레딩:

IO 멀티플렉싱: 하나의 스레드가 여러 소켓 상태를 추적하며 준비된 스레드 중 하나를 읽고 씁니다. IO 차단 + 멀티스레딩: 각 요청에 대해 새로운 서비스 스레드가 생성됩니다.

IO 멀티플렉싱 및 멀티스레딩에 적용 가능한 시나리오는 무엇입니까?

IO 다중화: 단일 연결의 요청 처리 속도에는 이점이 없습니다. 대규모 동시성: 하나의 스레드만 사용하여 많은 수의 동시 요청을 처리하므로 동시성 문제를 고려할 필요가 없으며 상대적으로 더 많은 요청을 처리할 수 있습니다. 더 적은 시스템 리소스를 소비합니다(스레드 예약 오버헤드가 필요하지 않음). 긴 연결에 적합합니다(다중 스레드 모드의 긴 연결은 쉽게 너무 많은 스레드를 발생시키고 빈번한 예약을 유발할 수 있음). IO 차단 + 멀티스레딩: 구현이 간단하고 시스템 호출에 의존하지 않습니다. 각 스레드에는 시간과 공간이 필요합니다. 스레드 수가 증가하면 스레드 예약 오버헤드가 기하급수적으로 증가합니다.

select/poll과 epoll은 다음과 같이 비교됩니다.

select/poll 시스템 호출:

// select 系统调用
int select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout); 
// poll 系统调用
int poll(struct pollfd fds[], nfds_t nfds, int timeout)；

select:

fd_set에 쿼리하여 준비된 fd가 있는지 확인합니다. fd가 있는 경우 시간 초과를 설정할 수 있습니다. 설명자)가 준비되었습니다. 또는 시간 초과 후 반환됩니다. fd_set은 비트 세트이며 크기는 커널을 컴파일할 때 상수이며 기본 크기는 1024입니다. 특징: 연결 수가 제한되어 있고 fd_set이 나타낼 수 있는 fd 수가 너무 적습니다. 선형 스캔: fd가 준비되었는지 확인하려면 fd_set의 한쪽 면(사용자 공간 및 커널 공간)을 통과해야 합니다. 연결 준비 상태 정보를 복사합니다.

poll:

연결 제한 해결: poll에서 너무 적은 수의 fd 문제를 해결하려면 선택의 fd_set를 pollfd 배열로 교체하세요. 데이터 복제: 사용자 공간 및 커널 공간, 연결 준비 상태 정보 복사.

epoll, 이벤트 이벤트 중심:

이벤트 메커니즘: 선형 스캔을 피하고, 각 fd에 대한 청취 이벤트를 등록하고, fd가 준비로 변경되면 fd를 준비 목록에 추가합니다. fd 수: 제한 없음(OS 수준 제한, 단일 프로세스에서 열 수 있는 fd 수).

select, poll, epoll:

I/O 다중화 메커니즘. I/O 멀티플렉싱은 여러 설명자를 모니터링하는 메커니즘을 사용합니다. 특정 설명자가 준비되면(일반적으로 읽기 준비 또는 쓰기 준비) 해당 읽기 및 쓰기 작업을 수행하도록 프로그램에 알릴 수 있습니다. 그러나 선택, 폴링 및 epoll은 본질적으로 동기식 I/O입니다. 사용자 프로세스는 읽기 및 쓰기(커널 공간에서 사용자 공간으로 복사)를 담당합니다. 읽기 및 쓰기 프로세스 중에는 비동기식 IO가 차단되지 않습니다. 사용자 프로세스가 읽기 및 쓰기를 담당해야 하며 비동기 IO는 커널 공간에서 사용자 공간으로 복사를 담당합니다.

Nginx의 동시 처리 기능

Nginx의 동시 처리 기능 정보: 동시 연결 수는 일반적으로 최적화 후 최대값은 약 1~3w로 유지될 수 있습니다. (메모리 및 CPU 코어 수는 다르므로 추가 최적화의 여지가 있습니다)

관련 권장 사항: nginx 튜토리얼

위 내용은 nginx가 왜 그렇게 빠른가요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!