Nginx 구성을 최적화하는 방법
소개
엔진엑스
Nginx는 때때로 압도적인 Apache 2에 대한 빠르고 가벼운 대안입니다. 그러나 최적의 성능을 얻으려면 다른 종류의 서버나 소프트웨어와 마찬가지로 Nginx를 조정해야 합니다.
요구 사항
- 초기 설정이 완료된 새로운 Debian 7 드롭릿.
- 드롭릿에는 새로 설치 및 구성된 Nginx 서버가 실행 중이어야 합니다. Debian Nginx Server Blocks 자습서를 사용해 보십시오.\n
- Linux 기초에 대한 충분한 이해.\n
작업자 프로세스 및 작업자 연결
조정해야 하는 처음 두 변수는 작업자 프로세스와 작업자 연결입니다. 각 설정으로 이동하기 전에 각 지시문이 무엇을 제어하는지 이해해야 합니다. worker_processes 지시문은 Nginx의 견고한 생명력입니다. 이 지시문은 가상 서버가 적절한 IP 및 포트에 바인딩되면 생성할 작업자 수를 알려주는 역할을 합니다. 코어당 하나의 작업자 프로세스를 실행하는 것이 일반적입니다. 이 이상은 시스템에 해를 끼치지 않지만 일반적으로 유휴 프로세스를 방치합니다.
worker_processes를 설정해야 하는 숫자를 파악하려면 설정에 있는 코어의 양을 살펴보세요. DigitalOcean 512MB 설정을 사용하는 경우 아마도 하나의 코어일 것입니다. 더 큰 설정으로 빠르게 크기를 조정하게 되면 코어를 다시 확인하고 그에 따라 이 숫자를 조정해야 합니다. cpuinfo를 greping하여 이를 수행할 수 있습니다.
grep processor /proc/cpuinfo | wc -l
이것이 값 1을 반환한다고 가정해 보겠습니다. 그러면 이것이 우리 머신의 코어 수입니다!
worker_connections
명령은 작업자 프로세스에 Nginx에서 동시에 서비스를 제공할 수 있는 사람 수를 알려줍니다. 기본값은 768입니다. 그러나 모든 브라우저가 일반적으로 서버당 최소 2개의 연결을 여는 것을 고려하면 이 숫자는 절반이 될 수 있습니다. 이것이 우리가 작업자 연결을 최대한으로 조정해야 하는 이유입니다. ulimit 명령을 실행하여 코어의 한계를 확인할 수 있습니다.
ulimit -n
더 작은 머신(512MB 드롭릿)에서 이 숫자는 아마도 1024로 표시될 것입니다. 이것은 좋은 시작 숫자입니다.
구성을 업데이트해 보겠습니다.
sudo nano /etc/nginx/nginx.conf
worker_processes 1;
worker_connections 1024;
서비스를 제공할 수 있는 클라이언트의 양은 코어의 양을 곱할 수 있음을 기억하십시오. 이 경우 초당 1024개의 클라이언트를 처리할 수 있습니다. 그러나 이것은 keepalive_timeout
지시문에 의해 더욱 완화됩니다.
버퍼
우리가 만들 수 있는 또 다른 매우 중요한 조정은 버퍼 크기입니다. 버퍼 크기가 너무 작으면 Nginx가 임시 파일에 써야 하므로 디스크가 계속 읽고 쓰게 됩니다. 결정을 내리기 전에 이해해야 할 몇 가지 지침이 있습니다.
client_body_buffer_size
: 클라이언트 버퍼 크기를 처리합니다. 즉, Nginx로 전송되는 모든 POST 작업을 의미합니다. POST 작업은 일반적으로 양식 제출입니다.
client_header_buffer_size
: 이전 지시문과 유사하지만 대신 클라이언트 헤더 크기만 처리합니다. 모든 의도와 목적을 위해 일반적으로 1K는 이 지시어에 적합한 크기입니다.
client_max_body_size
: 클라이언트 요청에 허용되는 최대 크기입니다. 최대 크기를 초과하면 Nginx에서 413 오류 또는 요청 엔터티가 너무 큼을 내보냅니다.
large_client_header_buffers
: 대형 클라이언트 헤더에 대한 최대 버퍼 수 및 크기입니다.
client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 2 1k;
타임아웃
시간 초과는 성능을 크게 향상시킬 수도 있습니다.
client_body_timeout
및 client_header_timeout
지시문은 요청 후 클라이언트 본문 또는 클라이언트 헤더가 전송될 때까지 서버가 기다리는 시간을 담당합니다. 본문이나 헤더가 모두 전송되지 않으면 서버에서 408 오류 또는 요청 시간 초과가 발생합니다.
keepalive_timeout
은 클라이언트와의 연결 유지를 위한 제한 시간을 지정합니다. 간단히 말해 Nginx는 이 기간이 지나면 클라이언트와의 연결을 닫습니다.
마지막으로 send_timeout
은 전체 응답 전송이 아니라 두 읽기 작업 사이에서만 설정됩니다. 이 시간 이후에 클라이언트가 아무 것도 사용하지 않으면 Nginx가 연결을 종료합니다.
client_body_timeout 12;
client_header_timeout 12;
keepalive_timeout 15;
send_timeout 10;
Gzip 압축
Gzip은 Nginx가 처리하는 네트워크 전송량을 줄이는 데 도움이 될 수 있습니다. 그러나 서버가 CPU 주기를 낭비하기 시작하므로 gzip_comp_level
을 너무 높게 높이면 주의하십시오.
gzip on;
gzip_comp_level 2;
gzip_min_length 1000;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain application/x-javascript text/xml text/css application/xml;
정적 파일 캐싱
변경되지 않고 정기적으로 제공되는 파일에 만료 헤더를 설정할 수 있습니다. 이 디렉티브는 실제 Nginx 서버 블록에 추가할 수 있습니다.
location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}
Nginx 서버의 파일 유형과 일치하도록 위의 배열에 있는 파일 유형을 추가하고 제거하십시오.
벌채 반출
Nginx는 VPS에 도달하는 모든 요청을 로그 파일에 기록합니다. 분석을 사용하여 이를 모니터링하는 경우 이 기능을 해제할 수 있습니다. access_log
지시문을 편집하기만 하면 됩니다.
access_log off;
파일을 저장하고 닫은 후 다음을 실행합니다.
sudo service nginx restart
결론
결국 적절하게 구성된 서버는 그에 따라 모니터링되고 조정되는 서버입니다. 위의 변수 중 어느 것도 고정되어 있지 않으며 각각의 고유한 사례에 맞게 조정해야 합니다. 더 나아가 로드 밸런싱 및 수평 확장에 대한 연구를 통해 시스템 성능을 향상시킬 수 있습니다. 이것은 우수한 시스템 관리자가 서버에 적용할 수 있는 많은 개선 사항 중 일부에 불과합니다.