사용자 도구

사이트 도구


nginx:performance

nginx Performance

worker와 connection

  • worker_processes는 CPU 혹은 CPU Core의 총 갯수와 동일하게 맞춘다.
    • grep processor /proc/cpuinfo | wc -l CPU 갯수
    • 하지만 보통은 4개 정도가 넘어가면 이미 최대 성능치일 경우가 많다.
  • worker_connections는 하나의 worker_process가 받을 수 있는 클라이언트 갯수이다.
    • 총 접속 가능 클라이언트 갯수(MaxClients)는 worker_processes * worker_connections로 지정된다.
    • Reverse Proxy 상태에서는 worker_processes * worker_connections / 4 이 값은 ulimit -n의 결과값(open files)보다 작아야 한다. 보통 1024면 충분하다.

운영체제 설정값

  • 실무에서는 Windows에서 nginx 사용하지 말 것.
  • 운영체제 nginx 실행 계정의 ulimit -a 값이 작으면 오류가 발생한다. worker_rlimit_nofile 값을 줘서 튜닝해본다.

버퍼

  • Proxy를 사용할 경우 버퍼의 크기가 너무 작으면 nginx는 임시 파일을 만들어 proxy에서 전달되는 내용을 저장하게 된다. 장비의 메모리 상황등을 참조하여 적당한 수준으로 늘려줘야 한다.
client_body_buffer_size 8K;
client_header_buffer_size 1k;
client_max_body_size 2m; # 파일 업로드를 2mb 이상할 예정이라면 이 값을 늘려줘야 한다.
large_client_header_buffers 2 1k;

timeout

지연시간이 길 경우 브라우저의 접속을 끊어서 서버 성능을 높여 주도록 한다.

client_body_timeout   10;
client_header_timeout 10;
keepalive_timeout     15;
send_timeout          10;
  • 혹시 대용량 트래픽시에 에러가 나는 것은 한계 트래픽에 가까웠을 때 timeout으로 인한 것은 아닐까? timeout을 높이면 에러가 안나는?

access log를 꺼라

  • js,image,css 등은 일반적으로 access 로그를 남길 필요가 없다. 해당 location에 대한 access log를 꺼서 Disk IO 부담을 줄여주도록 한다.
location /images {
    access_log off;
}

혹은

location ~* \.(js|css|png|jpg|jpeg|gif|ico) {
    access_log off;
}

Keep Alive 튜닝

  • keepalive를 무작정 선택하지 말고 성능 테스트를 해가며 조정해 볼 것.

Disk IO 병목

  • open_file_cache를 해주자.
     open_file_cache max=1000 inactive=20s; 
     open_file_cache_valid    30s; 
     open_file_cache_min_uses 2;
     open_file_cache_errors   on;

tcp_nopush, tcp_nodelay

  • 보통은 할 필요 없다.
  • 하면 성능 향상이 있을 수 있지만, 때로는 오히려 저하가 발생할 수도 있다. 따라서 꼭 테스트가 필요하다.
  • sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

Local Port 를 못 열어서 프록시 못하는 문제

nginx/performance.txt · 마지막으로 수정됨: 2019/05/23 14:59 저자 kwon37xi