면접 문제: Nginx 는 어떻게 높 은 병행 을 실현 합 니까?흔히 볼 수 있 는 최적화 수단 에는 어떤 것들 이 있 습 니까?

면접 문제:
Nginx 는 어떻게 병발 을 실현 합 니까?왜 Nginx 는 다 중 스 레 드 를 사용 하지 않 습 니까?Nginx 에서 흔히 볼 수 있 는 최적화 수단 은 어떤 것 이 있 습 니까?502 오류 의 원인 은 어떤 것 이 있 습 니까?
면접 관 심리 분석
주로 지원 자 들 이 NGINX 의 기본 원리 에 익숙 한 지 를 살 펴 보 는 것 이다. 대부분의 운영 자 들 이 많 고 적 으 면 NGINX 를 알 지만 정 작 원 리 를 아 는 사람 은 적 을 수 있 기 때문이다.그 원 리 를 알 아야 최 적 화 를 할 수 있다. 그렇지 않 으 면 그대로 옮 길 수 밖 에 없고 문제 가 생 겨 도 손 을 쓸 수가 없다.
피상 적 인 사람 은 일반적으로 웹 서버 를 만들어 웹 사 이 트 를 만든다.초급 운영 자 는 HTTPS 를 만 들 고 역방향 대 리 를 설정 할 수 있 습 니 다.중급 운영 비 는 upstream 을 정의 하고 정규 판단 을 작성 합 니 다.늙 은 새 가 개성 을 최적화 시 키 고 ACL 을 쓸 수 있 으 며 소스 코드 를 바 꿀 수도 있다.
면접 문제 분석.
1. Nginx 는 어떻게 높 은 병발 을 실현 합 니까?
비동기, 비 차단, epoll 과 대량의 바 텀 코드 를 사용 하여 최적화 되 었 습 니 다.
서버 가 하나의 프로 세 스 로 request 를 책임 지 는 방식 을 사용한다 면 프로 세 스 수 는 병발 수 입 니 다.정상 적 인 상황 에서 많은 프로 세 스 가 기다 리 고 있 을 것 이다.
nginx 는 master 프로 세 스, 여러 woker 프로 세 스 모드 를 사용 합 니 다.

master 프로 세 스 는 주로 수집, 배포 요청 을 책임 집 니 다.요청 이 올 때마다 master 는 워 커 프로 세 스 를 끌 어 올 려 이 요청 을 처리 합 니 다.

이 동시에 master 프로 세 스 도 woker 의 상 태 를 감시 하고 높 은 신뢰성 을 확보 합 니 다

woker 프로 세 스 는 일반적으로 cpu 핵심 수 와 일치 하도록 설정 합 니 다.nginx 의 woker 프로 세 스 는 같은 시간 에 처리 할 수 있 는 요청 수 는 메모리 제한 만 받 고 여러 요청 을 처리 할 수 있 습 니 다.

Nginx 의 비동기 비 차단 작업 방식 은 그 중의 대기 시간 을 이용 하고 있다.기 다 려 야 할 때 이 프로 세 스 들 은 한가 하 게 대기 하기 때문에 소수의 프로 세 스 가 대량의 병발 문 제 를 해결 하 는 것 으로 나 타 났 다.
요청 이 들 어 올 때마다 워 커 프로 세 스 가 처 리 됩 니 다.그러나 전과정 의 처리 가 아니 라 어느 정도 까지 처 리 했 을 까?상류 (백 엔 드) 서버 에 request 를 전송 하고 요청 이 돌아 오 기 를 기다 리 는 등 차단 이 발생 할 수 있 는 곳 으로 처리 합 니 다.그러면 이 처 리 된 워 커 는 똑똑 합 니 다. 그 는 요청 을 보 낸 후에 "upstream 이 돌아 오 면 알려 주세요. 제 가 계속 하 겠 습 니 다" 라 는 사건 을 등록 할 것 입 니 다.그래서 그 는 쉬 러 갔다.이때 리퀘스트 가 다시 들 어 오 면 그 는 곧 이런 방식 으로 처리 할 수 있다.상류 서버 가 돌아 오 면 이 사건 이 발생 하고 워 커 가 인수 할 수 있 으 며 이 request 는 계속 내 려 갈 수 있 습 니 다.
2. 왜 Nginx 는 다 중 스 레 드 를 사용 하지 않 습 니까?
Apache: 여러 개의 프로 세 스 나 스 레 드 를 만 들 고 모든 프로 세 스 나 스 레 드 는 cpu 와 메모 리 를 할당 합 니 다.
Nginx: 단일 라인 으로 비동기 비 차단 처리 요청 (관리 자 는 Nginx 메 인 프로 세 스 의 작업 프로 세 스 수 를 설정 할 수 있 습 니 다) (epoll) 을 사용 합 니 다. 모든 요청 에 cpu 와 메모리 자원 을 할당 하지 않 고 대량의 자원 을 절약 하 는 동시에 대량의 CPU 컨 텍스트 전환 도 감소 합 니 다.그래서 Nginx 는 더 높 은 병행 을 지원 하 게 되 었 습 니 다.
3. Nginx 에서 흔히 볼 수 있 는 최적화 설정 은 어떤 것 이 있 습 니까?
(1) 조정 workerprocesses
Nginx 가 생 성 할 worker 수 를 말 합 니 다. 가장 좋 은 실천 은 CPU 마다 작업 프로 세 스 를 실행 하 는 것 입 니 다.
시스템 의 CPU 핵심 수 파악, 입력

$ grep processor / proc / cpuinfo | wc -l 

(2) 최대 화 workerconnections
Nginx 웹 서버 는 서 비 스 를 동시에 제공 할 수 있 는 클 라 이언 트 수 입 니 다.workerprocesses 결합 사용 시 초당 서비스 가능 한 최대 클 라 이언 트 수 획득
최대 클 라 이언 트 수 / 초 = 작업 프로 세 스 * 작업 자 연결 수
Nginx 의 모든 잠재력 을 극 대화 하기 위해 서 는 작업 자 연결 을 핵심 으로 한 번 에 실행 할 수 있 는 최대 프로 세 스 수 1024 로 설정 해 야 합 니 다.
(3) Gzip 압축 사용 하기
파일 크기 를 압축 하여 클 라 이언 트 http 의 전송 대역 폭 을 줄 였 기 때문에 페이지 로드 속 도 를 높 였 습 니 다.
제안 한 gzip 설정 예 는 다음 과 같 습 니 다. (http 부분 에서)
(4) 정적 파일 에 캐 시 사용 하기
정적 파일 에 캐 시 를 사용 하여 대역 폭 을 줄 이 고 성능 을 향상 시 킬 수 있 습 니 다. 아래 명령 을 추가 하여 컴퓨터 캐 시 웹 페이지 의 정적 파일 을 제한 할 수 있 습 니 다.

location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {  
expires 365d;  
} 

(5) Timeouts
keepalive 연결 은 연결 을 열 고 닫 는 데 필요 한 CPU 와 네트워크 비용 을 줄 이 고 최 적 성능 을 조정 해 야 할 변 수 를 얻 었 습 니 다. 참고 할 수 있 습 니 다.
(6) access 비활성화logs
로그 기록 에 접근 합 니 다. 모든 nginx 요청 을 기록 하기 때문에 대량의 CPU 자원 을 소모 하여 nginx 성능 을 떨 어 뜨 렸 습 니 다.
접근 로그 기록 을 완전히 사용 하지 않 습 니 다.

access_log off; 

접근 로그 기록 이 있어 야 한다 면 접근 로그 버퍼 를 사용 합 니 다.

access_log /var/log/nginx/access.log    = 16k 

4. 502 잘못 보고 한 원인 은 어떤 것 이 있 습 니까?
(1) FastCGI 프로 세 스 가 시작 되 었 는 지 여부
(2) FastCGI 작업 자 프로 세 스 수가 부족 한 지 여부
(3) FastCGI 를 너무 오래 실행
(4) FastCGI Buffer 부족
nginx 는 apache 와 마찬가지 로 전단 버퍼 제한 이 있어 버퍼 파 라 메 터 를 조정 할 수 있 습 니 다.

fastcgi_buffer_size 32k;  
fastcgi_buffers 8 32k; 

(5) 프 록 시 버퍼 부족
하면, 만약, 만약...

proxy_buffer_size 16k;  
proxy_buffers 4 16k; 

(6) phop 스 크 립 트 가 너무 오래 실행 되 었 습 니 다.
php - fpm. conf 의

<value name="request_terminate_timeout">0svalue> 

시간