웹사이트 검색

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_timeoutclient_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

결론

결국 적절하게 구성된 서버는 그에 따라 모니터링되고 조정되는 서버입니다. 위의 변수 중 어느 것도 고정되어 있지 않으며 각각의 고유한 사례에 맞게 조정해야 합니다. 더 나아가 로드 밸런싱 및 수평 확장에 대한 연구를 통해 시스템 성능을 향상시킬 수 있습니다. 이것은 우수한 시스템 관리자가 서버에 적용할 수 있는 많은 개선 사항 중 일부에 불과합니다.

제출자: Alex Kavon