사용자 도구

사이트 도구


nginx:performance

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판
이전 판
nginx:performance [2015/02/04 19:40]
kwon37xi
nginx:performance [2024/02/15 12:16] (현재)
kwon37xi [Keep Alive 튜닝]
줄 9: 줄 9:
   * [[http://www.cyberciti.biz/faq/nginx-see-active-connections-connections-per-seconds/|nginx: See Active connections / Connections Per Seconds]]   * [[http://www.cyberciti.biz/faq/nginx-see-active-connections-connections-per-seconds/|nginx: See Active connections / Connections Per Seconds]]
   * [[http://java.dzone.com/articles/static-file-best-practices|Static File Best Practices on Nginx-Clojure | Javalobby]]   * [[http://java.dzone.com/articles/static-file-best-practices|Static File Best Practices on Nginx-Clojure | Javalobby]]
 +  * [[http://java.dzone.com/articles/thread-pools-nginx-boost|Thread Pools in NGINX Boost Performance 9x!]]
 +  * [[http://www.slideshare.net/btolley/nginx-performance-ppt-2015|Accelerating Nginx Web Server Performance]]
 +  * [[https://dzone.com/articles/tuning-nginx|Tuning NGINX: Part I]]
 +  * [[https://www.sitepoint.com/apache-vs-nginx-performance-optimization-techniques/|Apache vs Nginx Performance: Optimization Techniques — SitePoint]]
 +  * [[https://www.slashroot.in/nginx-web-server-performance-tuning-how-to-do-it|Nginx Performance Tuning: How to do it]]
 +  * [[https://github.com/denji/nginx-tuning/blob/master/README.md|nginx-tuning/README.md at master · denji/nginx-tuning]]
 +  * [[https://couplewith.tistory.com/entry/%EA%BF%80%ED%8C%81%EA%B3%A0%EC%84%B1%EB%8A%A5-Nginx%EB%A5%BC%EC%9C%84%ED%95%9C-%ED%8A%9C%EB%8B%9D4-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EB%B0%8F-CPU-%ED%8A%9C%EB%8B%9D%ED%95%98%EA%B8%B0-Processor|[꿀팁]고성능 Nginx를위한 튜닝(4)- 메모리 및 CPU 튜닝하기 (Processor)]]
 +  * [[https://couplewith.tistory.com/m/entry/%EA%BF%80%ED%8C%81-%EA%B3%A0%EC%84%B1%EB%8A%A5-Nginx%EB%A5%BC%EC%9C%84%ED%95%9C-%ED%8A%9C%EB%8B%9D6-%EB%A1%9C%EA%B7%B8-%EB%B6%80%ED%95%98-%EC%A4%84%EC%9D%B4%EA%B8%B0|[꿀팁] 고성능 Nginx를위한 튜닝(6)-로그 부하 줄이기]]
  
-====== worker와 connection ======+===== worker와 connection =====
   * **''worker_processes''**는 CPU 혹은 CPU Core의 총 갯수와 동일하게 맞춘다.   * **''worker_processes''**는 CPU 혹은 CPU Core의 총 갯수와 동일하게 맞춘다.
 +    * ''grep processor /proc/cpuinfo | wc -l'' CPU 갯수
     * 하지만 보통은 4개 정도가 넘어가면 이미 최대 성능치일 경우가 많다.     * 하지만 보통은 4개 정도가 넘어가면 이미 최대 성능치일 경우가 많다.
   * **''worker_connections''**는 하나의 ''worker_process''가 받을 수 있는 클라이언트 갯수이다.   * **''worker_connections''**는 하나의 ''worker_process''가 받을 수 있는 클라이언트 갯수이다.
     * 총 접속 가능 클라이언트 갯수(MaxClients)는 ''worker_processes * worker_connections''로 지정된다.     * 총 접속 가능 클라이언트 갯수(MaxClients)는 ''worker_processes * worker_connections''로 지정된다.
-    * Reverse Proxy 상태에서는 ''worker_processes * worker_connections / 4'' +    * Reverse Proxy 상태에서는 ''worker_processes * worker_connections / 4'' 이 값은 **''ulimit -n''의 결과값(open files)보다 작아야** 한다. 보통 1024면 충분하다.
-    * 이 값은 **''ulimit -n''의 결과값보다 작아야** 한다. 보통 1024면 충분하다.+
  
-====== 운영체제 설정값 ======+ 
 +===== 운영체제 설정값 =====
   * 실무에서는 Windows에서 nginx 사용하지 말 것.   * 실무에서는 Windows에서 nginx 사용하지 말 것.
   * 운영체제 nginx 실행 계정의 ''ulimit -a'' 값이 작으면 오류가 발생한다. [[http://wiki.nginx.org/CoreModule#worker_rlimit_nofile|worker_rlimit_nofile]] 값을 줘서 튜닝해본다.   * 운영체제 nginx 실행 계정의 ''ulimit -a'' 값이 작으면 오류가 발생한다. [[http://wiki.nginx.org/CoreModule#worker_rlimit_nofile|worker_rlimit_nofile]] 값을 줘서 튜닝해본다.
  
-====== 버퍼 ======+===== 버퍼 =====
   * Proxy를 사용할 경우 버퍼의 크기가 너무 작으면 nginx는 임시 파일을 만들어 proxy에서 전달되는 내용을 저장하게 된다. 장비의 메모리 상황등을 참조하여 적당한 수준으로 늘려줘야 한다.   * Proxy를 사용할 경우 버퍼의 크기가 너무 작으면 nginx는 임시 파일을 만들어 proxy에서 전달되는 내용을 저장하게 된다. 장비의 메모리 상황등을 참조하여 적당한 수준으로 늘려줘야 한다.
 <code> <code>
줄 31: 줄 40:
 </code> </code>
  
-====== timeout ======+===== timeout =====
 지연시간이 길 경우 브라우저의 접속을 끊어서 서버 성능을 높여 주도록 한다. 지연시간이 길 경우 브라우저의 접속을 끊어서 서버 성능을 높여 주도록 한다.
 <code> <code>
줄 40: 줄 49:
 </code> </code>
   * 혹시 대용량 트래픽시에 에러가 나는 것은 한계 트래픽에 가까웠을 때 timeout으로 인한 것은 아닐까? timeout을 높이면 에러가 안나는?   * 혹시 대용량 트래픽시에 에러가 나는 것은 한계 트래픽에 가까웠을 때 timeout으로 인한 것은 아닐까? timeout을 높이면 에러가 안나는?
-====== access log를 꺼라 ======+ 
 +===== access log를 꺼라 =====
   * js,image,css 등은 일반적으로 access 로그를 남길 필요가 없다. 해당 location에 대한 access log를 꺼서 Disk IO 부담을 줄여주도록 한다.   * js,image,css 등은 일반적으로 access 로그를 남길 필요가 없다. 해당 location에 대한 access log를 꺼서 Disk IO 부담을 줄여주도록 한다.
 <code> <code>
줄 46: 줄 56:
     access_log off;     access_log off;
 } }
 +
 +혹은
 +
 +location ~* \.(js|css|png|jpg|jpeg|gif|ico) {
 +    access_log off;
 +}
 +</code>
 +
 +===== Keep Alive 튜닝 =====
 +  * [[web:performance|Web 성능 향상]] 참조.
 +  * keepalive를 무작정 선택하지 말고 성능 테스트를 해가며 조정해 볼 것.
 +  * [[https://www.nginx.com/blog/http-keepalives-and-web-performance/|Using NGINX as an Accelerating Proxy for HTTP Servers]]
 +
 +===== Disk IO 병목 =====
 +  * [[http://wiki.nginx.org/HttpCoreModule#open_file_cache|open_file_cache]]를 해주자.<code>
 + open_file_cache max=1000 inactive=20s; 
 + open_file_cache_valid    30s; 
 + open_file_cache_min_uses 2;
 + open_file_cache_errors   on;
 +</code>
 +
 +===== tcp_nopush, tcp_nodelay =====
 +  * 보통은 할 필요 없다.
 +  * 하면 성능 향상이 있을 수 있지만, 때로는 오히려 저하가 발생할 수도 있다. 따라서 꼭 테스트가 필요하다.
 +  * <code>
 +sendfile on;
 +tcp_nopush on;
 +tcp_nodelay on;
 +</code>
 +  * [[http://man7.org/linux/man-pages/man2/sendfile.2.html|sendfile]]
 +  * [[http://wiki.nginx.org/HttpCoreModule#tcp_nopush|tcp_nopush]]
 +  * [[http://wiki.nginx.org/HttpCoreModule#tcp_nodelay|tcp_nodelay]]
 +
 +===== Local Port 를 못 열어서 프록시 못하는 문제 =====
 +  * [[https://ma.ttias.be/nginx-cannot-assign-requested-address-for-upstream/|Nginx: Cannot assign requested address for upstream]]
 +  * [[https://ma.ttias.be/linux-increase-ip_local_port_range-tcp-port-range/|Linux increase ip_local_port_range TCP port range]]
 +<code sh>
 +$ echo 15000 64000 > /proc/sys/net/ipv4/ip_local_port_range
 </code> </code>
 +  
  
nginx/performance.1423046432.txt.gz · 마지막으로 수정됨: 2015/02/04 19:40 저자 kwon37xi