인터뷰 질문 :
Nginx와는 Nginx에 멀티 쓰레딩을 사용하지 않는 이유는 무엇입니까? 동시 달성하는 방법은? 일반적인 최적화 Nginx에 무엇을 의미? 오류 502의 가능한 이유는 무엇입니까?
면접관 심리 분석
주로 대부분의 지점의 nginx가 더 많거나 적은 모든 것을 알고 있기 때문에 잘 알고, 운영 및 유지 보수 인력 여부를 Nginx에 대한 후보자의 기본 원리를 볼 수 있지만, 정말 극소수의 원리를 이해 할 수있다. 최적화를 수행하기 위해 그 원리를 이해, 또는 단지 아직도 문제가 시작하는 방법처럼 이동합니다.
, 베테랑은 성능 최적화 될, 일반 판사 쓰기, 상류 중간 수준의 운영 및 유지 보수의 정의, 주요 운영 및 유지 보수, HTTPS를 제시 역방향 프록시를 구성 할 수 있습니다, 모피 사람들은 일반적으로 웹 사이트를 설정 웹 서버, 수, 이해 ACL 물품,이 소스 코드를 변경하는 변경하는 것이 가능하다 (작은 일련의 소스 코드를 변경하는 능력을 나타낸다 없음).
얼굴 질문 분석
1. Nginx에 높은 동시성을 달성하는 방법은?
비동기 비 차단하고, 내부는 epoll 코드 최적화의 큰 숫자를 사용합니다.
서버가 프로세스 방식의 요청에 대한 책임이 사용하는 경우, 다음 수는 동시 프로세스의 수입니다. 정상적인 상황에서는 많은 진전이 기다리고있다가있을 것입니다.
마스터 프로세스의 nginx를 사용, 여러 woker 모드 프로세스.
- 마스터 과정은 수집, 분배 요청에 대한 일차적 책임이있다. 요청이 끝날 때마다, 마스터는 작업자 프로세스가 요청을 처리 할 책임이 끌어 올려서.
- 동시에 마스터 프로세스는 상태 woker 높은 신뢰성을 보장 할 책임이 모니터링
- woker 프로세스는 일반적으로 CPU 코어의 개수와 일치하도록 설정된다. 같은 시간에의 nginx의 woker의 프로세스는 메모리 제한에 의해 처리 할 수있는 요청의 수는 여러 요청을 처리 할 수 있습니다.
Nginx에 비동기까지 사용 대기 시간 사이에있는 동작의 비 블록 모드. 당신은 프로세스의 작은 숫자의 성능이 동시성 문제를 많이 해결할 수 있도록 이러한 프로세스는 독립을 확보하기 위해 기다릴 필요합니다.
각 요청에 제공, 처리하는 작업자 프로세스가있을 것입니다. 하지만 전체 치료 과정과 가능한 서버가 업스트림 (백엔드)에 요청을 전달과 같은 장애물, 그리고 요청이 반환을 기다리는으로 어느 정도? 장소를 처리 할 수 있습니다. 그래서,이 과정 노동자는 그 요청을 전송 한 후 이벤트를 등록하는 것, 똑똑 : "상류 반환하는 경우, 알려, 나는 다음 건조 갔다." 그래서 그는 휴식을했다. 또 다른 요청이 들어 오면이 시점에서, 그는 신속하게이 방법으로 처리 할 수 있습니다. 업스트림 서버가 반환되면, 작업자는이 요청은 아래로 갈 것이다, 이상 걸릴 것입니다,이 이벤트를 트리거합니다.
2. 왜 Nginx에 멀티 스레딩을 사용하지 않는 이유는 무엇입니까?
아파치 : 서버 자원이 부족했던 총회에서 복잡, 여러 프로세스 또는 스레드를 생성하고 (노동자가 perfork 지원 동시성보다 높은, 그래서 작은 것보다 멀티 스레딩 과정) 각 스레드 또는 프로세스가 CPU와 메모리를 할당합니다.
Nginx의 : 단일 스레드 비동기 또한, 각 요청의 CPU와 메모리 자원을 할당 할 수없는 것, 비 차단 처리 요청 (는 epoll을) 많은 자원을 저장하지만, (의 Nginx의 마스터 과정을 구성 할 수 있습니다 관리자 업무 프로세스의 수)는을 감소 CPU 컨텍스트 스위칭 다량. 그래서 Nginx에 높은 동시성을 지원합니다.
3. Nginx의 구성 일반적인 최적화 무엇입니까?
(1) 조정 worker_processes
노동자의 Nginx의 수를 나타냅니다는 가장 좋은 방법은 작업자 프로세스를 실행하는 각 CPU입니다 발생합니다.
시스템의 CPU 코어를 입력
$ grep processor / proc / cpuinfo | wc -l
复制代码(2) worker_connections을 극대화
Nginx의 웹 서버는 동시에 다수의 클라이언트를 제공 할 수 있습니다. worker_processes와 결합하면, 두 번째 캔 당 클라이언트 서비스의 수를 최대화하기
클라이언트 / 초 = * 작업자 작업자 프로세스 연결의 최대 수
Nginx에의 잠재력을 극대화하기 위해, 노동자는 1024의 숫자를 실행할 수있는 최대 허용 코어를 설정하는 과정에 연결해야합니다.
(3) Gzip 압축 사용
따라서 페이지 로딩 속도를 향상, 전송 대역폭 HTTP 클라이언트를 감소, 파일 크기를 압축
GZIP 구성 예는 HTTP에서 권장 :( 부분) 이하
(4) 정적 파일 캐싱 활성화
대역폭을 줄이고 성능을 향상시키기 위해 정적 파일 캐싱을 사용하면, 당신은 정적 컴퓨터 파일을 캐시 페이지를 정의하려면 다음 명령을 추가 할 수 있습니다 :
location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}
复制代码(5) 제한 시간
킵 얼라이브 연결이 조정될 필요가있다 최적의 성능 변수 참조를 구하는 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를 버퍼
Nginx에 버퍼링 한계 말단부 아파치, 버퍼 파라미터들이 조정될 수있다
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
复制代码(5) 프록시 버퍼 충분히
당신이 프록시를 사용하는 경우, 조정
proxy_buffer_size 16k;
proxy_buffers 4 16k;
复制代码(6) PHP 스크립트 실행 시간이 너무 깁니다
의 PHP-fpm.conf
<value name="request_terminate_timeout">0s</value>
复制代码한 번에 0