높 고 낮은 nginx 최적화

무엇이 높 은 병발 입 니까?
높 은 병발 (High Concurrency) 은 인터넷 분포 식 시스템 구조 디자인 에서 반드시 고려 해 야 할 요소 중 하나 로 디자인 을 통 해 시스템 이 많은 요 구 를 동시에 처리 할 수 있 도록 하 는 것 을 말한다.높 은 병발 과 관련 하여 자주 사용 하 는 일부 지 표 는 응답 시간 (Response Time), 스루풋 (Throughput), 초당 조회 율 QPS (Query Per Second), 병발 사용자 수 등 이 있다.응답 시간: 시스템 이 요청 에 응답 하 는 시간 스루풋: 단위 시간 내 처리 요청 수량.QPS: 초당 응답 요청 수
어떻게 시스템 의 병발 능력 을 향상 시 킵 니까?
인터넷 분포 식 구조 디자인 으로 시스템 의 병행 능력 을 향상 시 키 는 방식 은 주로 두 가지 가 있다. 수직 확장 (Scale Up) 과 수평 확장 (Scale Out) 이다.수직 확장: 단기 처리 능력 향상.수직 확장 방식 은 또 두 가지 가 있다.단기 하드웨어 성능 향상 단기 구조 성능 수준 확장: 서버 증가, 클 러 스 터.
인터넷 업무 의 발전 이 매우 빠 른 초기 에 예산 이 문제 가 아니라면 '단기 하드웨어 성능 강화' 방식 으로 시스템 의 병행 능력 을 향상 시 키 는 것 을 강력 히 건의 했다. 이 단계 에 회사 의 전략 은 업 무 를 발전 시 키 는 데 시간 을 뺏 는 것 이 고 '단기 하드웨어 성능 강화' 는 가장 빠 른 방법 이기 때문이다.단기 하드웨어 의 성능 을 향상 시 키 든 단기 구조의 성능 을 향상 시 키 든 모두 치 명 적 인 부족 이 있다. 단기 성능 은 항상 한계 가 있다.그래서 인터넷 분포 식 구조 디자인 이 높 고 최종 해결 방안 은 수평 확장 이다.수평 확장: 서버 수 를 늘 리 면 시스템 성능 을 선형 으로 확장 할 수 있 습 니 다.
nginx 설정 흐름 제한
세 가지 실현 방식 limitconn_zone limit_req_zone ngx_http_upstream_module 앞의 두 가 지 는 클 라 이언 트 (즉 단일 IP 제한) 에 만 사용 할 수 있 습 니 다.
1.limit_conn_zone

http{
    limit_conn_zone $binary_remote_addr zone=one:10m;
    server{
        ...
        limit_conn one 10;#                  
        ...
    }
}

그 중에서 "limit conn one 10" 은 server 층 에 두 면 전체 server 에 유효 할 수도 있 고 location 에 두 면 단독 location 에 만 유효 합 니 다. 이 설정 은 클 라 이언 트 의 병렬 연결 수 는 10 개 밖 에 안 됩 니 다.
2.limit_req_zone

http{
    limit_req_zone $binary_remote_addr zone=req_one:10m rate=1r/s;
    server{
        ...
        limit_req zone=req_one burst=120;
        ...
    }
}

그 중에서 'limit req zone = req one burst = 120' 은 server 층 에 두 면 전체 server 에 유효 할 수도 있 고 location 에 두 면 단독 location 에 만 유효 rate = 1r / s 라 는 뜻 은 주소 당 1 초 에 한 번 만 요청 할 수 있다 는 뜻 이다. 즉, 토 큰 통 burst = 120 은 모두 120 개의 토 큰 이 있 고 매 초 에 1 개의 토 큰 만 추가 되 며 120 개의 토 큰 이 발 급 된 후에더 나 온 요청 은 503 으로 돌아 갑 니 다.
3.ngx_http_upstream_module (추천)

#               
upstream xxx{
    server 127.0.0.1:8080 max_conns=10;
    server 127.0.0.1:8081 max_conns=10;
}

높 고 낮은 nginx 보안 설정

#    
http{
    server_tokens off;
}

#IP  
#     ：
location / {
    allow 192.168.1.1；
    deny all;
}

#     ：
location / {
    deny 192.168.1.1；
    allow all;
}

#    
location /logs{
    autoindex on;
    root /opt/nginx/;
}

location ^/logs~*\.(log|txt)$ {
    add_header Content-Type text/plain;
    root /opt/nginx/;
}

#    
HTTPS  

nginx 설정 프로 세 스 수, 병발 수, 시스템 최적화

#  nginx      ，     
    worker_processes 2;    #    CPU    
    events{
        worker_connection 65535;
    }

#      
[root@proxy ~]# ulimit -a #         
[root@proxy ~]# ulimit -Hn 100000 #        
[root@proxy ~]# ulimit -Sn 100000 #      
[root@proxy ~]# vim /etc/security/limits.conf
 ... 
* soft nofile 100000 
* hard nofile 100000
#  /   /                

#  
[root@proxy ~]# ab -n 2000 -c 2000 http://192.168.136.131/ #      ,        

nginx 긴 연결
nginx 긴 연결 짧 은 연결, 서버 의 재해 방지 능력 강화
장면: HTTP 1.1 이후 HTTP 프로 토 콜 은 지속 적 인 연결, 즉 긴 연결 을 지원 합 니 다. 한 TCP 연결 에서 여러 개의 HTTP 요청 과 응답 을 전송 할 수 있 고 연결 을 구축 하고 닫 는 소모 와 지연 을 줄 일 수 있다 는 장점 이 있 습 니 다.만약 에 저희 가 nginx 를 역방향 프 록 시 나 부하 균형 으로 사용 하면 클 라 이언 트 에서 온 긴 연결 요청 이 짧 은 연결 로 서버 에 전 송 됩 니 다. 긴 연결 을 지원 하기 위해 서 는 nginx 서버 에 설정 을 해 야 합 니 다.
요구: nginx 를 사용 할 때 긴 연결 을 하려 면 다음 과 같은 두 가 지 를 해 야 합 니 다. 1: client 에서 nginx 까지 는 긴 연결 2: nginx 에서 server 까지 는 긴 연결 입 니 다. 클 라 이언 트 에 있어 nginx 는 사실 server 의 역할 을 합 니 다. 반대로 server 에 있어 nginx 는 client 입 니 다.
설정: 클 라 이언 트 와 Nginx 사이 에 긴 연결 을 유지 하려 면 1: 클 라 이언 트 가 보 낸 요청 은 "keep - alive" header 를 휴대 해 야 합 니 다.2: Nginx 설정 지원 keep - alive
nginx 압축
gzip 압축 작용: 응답 보 를 12098 ℃ 로 보 내기 전에 스토리 보드 압축 기능 을 시작 할 수 있 습 니 다. 이것 은 대역 폭 을 효과적으로 절약 하고 12220 ℃ 에서 클 라 이언 트 의 속 도 를 높 일 수 있 습 니 다. 압축 은 nginx 의 cpu 성능 을 소모 합 니 다.gzip 압축 은 http, server, location 모듈 에서 설정 할 수 있 습 니 다.
nginx 상태 모니터링

#  nginx     （      ：nginx.conf）
#      ：
#  nginx      
location /NginxStatus{
    stub_status on;
    access_log off;
}
#    ：
./configure --prefix=/opt/nginx/ --with-http_stub_status_module

#      nginx
#            
http://192.168.1.1/NginxStatus  

#    ：
#        active connections 
#     n    ,     n   ,      n    server accepts handled requests 
#         waiting、reading、writing 
reading —      Header   .            ，        writing  ，       
writing —          Header   .          ，        ，       。 
waiting —   keep-alive               . 
     waiting       ，        。    reading+writing              。

#  Nginx     ：
ps -ef|grep nginx | wc -l 

#  Web   TCP    ：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

#  ： 
CLOSED #             
LISTEN #           
SYN_RECV #          ，     
SYN_SENT #      ，       
ESTABLISHED #        /        
FIN_WAIT1 #         
FIN_WAIT2 #         
ITMED_WAIT #         
CLOSING #         
TIME_WAIT #            
LAST_ACK #