Nginx 성능 최적화

Nginx는 매우 인기 있고 성숙한 웹 서버이자 예비 프록시 서버입니다. 그러나 다양한 비즈니스 시나리오에 따라 가장 적합한 구성이 필요합니다. 많은 테스트와 연습, 그리고 지속적인 최적화와 개선이 필요합니다. 최근 사용자 호출 수가 100만 건을 넘은 후 몇 가지 문제가 발생했습니다. 그다지 복잡하지는 않지만 이를 해결하는 데 오랜 시간이 걸리고 많은 경험이 축적되었습니다.

실제로 이 문제는 일부 고객에게서 통화 시간이 초과되었다고 보고되었지만 자체 시스템 모니터링에서는 수십 밀리초 정도만 발생하는 것으로 나타났습니다. 확실히 시간 초과가 발생하지 않습니다. 네트워크 때문인지 의심했지만 몇 번 발생하고 나면 이 문제가 우연이 아닐 수도 있고 뿌리 깊은 이유가 있어야 한다는 막연한 느낌이 들었습니다.

저희 서비스는 기업 고객을 대상으로 하기 때문에 각 고객의 통화량이 매우 많더라도 각 기업 고객은 향후 수천 명의 고객이 있더라도 몇 개의 공용 네트워크 IP만 보유할 수 있습니다. 이러한 동시 연결을 쉽게 지원합니다. 따라서 먼저 네트워크에서 Nginx 긴 연결을 최적화하고 긴 연결을 5秒钟의 원래 구성에서 5分钟로 변경하고 매번 연결 요청 수를 기본 100에서 1000으로 조정했습니다.

<code>keepalive_timeout  300;
keepalive_requests 1000;</code>

조정이 완료되면 netstat -anp 명령을 통해 새로운 연결 요청 횟수가 감소하는 것을 확인할 수 있는데, 이는 오랜 연결이 작동했음을 나타냅니다. 그러나 잠시 후에도 여전히 고객 통화 시간 초과가 발생한 것으로 나타났습니다. Nginx 로그에서 요청 시간이 여전히 1초를 초과하고 일부는 아래와 같이 최대 약 20초까지 지속되는 것을 확인할 수 있습니다.

그리고 Zabbix 모니터링에서 발견된 현상은 연결 쓰기 또는 활성 횟수가 갑자기 증가하면 요청 시간에 따라 시간 초과가 더 많아지는 현상입니다.

애플리케이션 로그를 보면 실행 시간이 길지 않은 것으로 나타났습니다.

애플리케이션은 비즈니스 시작부터 실행부터 실행 결과까지의 시간에 Tomcat 컨테이너의 실행 시간은 포함되지 않습니다. 외부 요청의 실행 경로는 다음과 같습니다.

<code>client --> Nginx -->  Tomcat --> App</code>

Tomcat 컨테이너 자체의 실행에 문제가 있는 걸까요? Tomcat 요청 로그를 넣어서 호출한 후 이 시점 전후의 실행도 정상인 것을 확인했습니다:

요청 경로를 분석해 보면 Nginx to Tomcat 레이어에 몇 가지 문제가 있는 것 같습니다. 이 문제를 해결하는 동안 갑자기 약 30초의 시간 초과가 많이 발생하는 것을 발견했습니다. Zabbix에서도 아래와 같이 connection writing이 매우 높은 것으로 관찰되었습니다.

동시에 TIME_WAIT의 연결 수가 유난히 많은 것으로 나타났으며, 현상 및 패킷 캡처 분석 결과를 보면 일부 고객이 긴 연결을 설정하지 않은 것으로 보입니다. 🎜>을(를) 5분으로 설정하면 많은 수의 연결 대기 시간이 초과되었습니다. 당시에는 keepalive_timeout 파일을 편집하고 다음 두 매개변수를 추가하여 연결을 재사용했습니다. /etc/sysctl.conf

적용 후 빠르게 200 이하로 떨어졌습니다. Zabbix 모니터링에서도 확인할 수 있습니다.

<code>net.ipv4.tcp_tw_reuse = 1 #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 #表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。</code>

및 연결 활성화` 모두 크게 감소했지만 문제가 완전히 해결되지는 않았으며 기타 이유도 있습니다. 반드시 발견되어야 합니다.

connection writing

Nginx의

은 클라이언트가 수신한 첫 번째 바이트부터 호출 백엔드의 업스트림까지의 시간을 나타냅니다. 서버가 비즈니스 로직 처리를 완료하고 반환된 결과를 모두 클라이언트에 다시 쓸 때까지의 시간입니다. 업스트림 서버를 호출하는 시간을 인쇄할 수 있다면 문제의 범위를 좁히는 것이 더 쉬울 것입니다. 다행히 Nginx에는 두 가지가 있습니다. 백엔드 서버에서 요청한 시간과 IP 주소입니다. nginx.conf 파일에서 로그 형식을 다음과 같이 수정합니다.

reqeust_time

로그를 다시 보면 알 수 있습니다. 특히 긴 호출의 대부분은 동일한 서버에서 발생합니다. 기계:

<code># $upstream_response_time 后端应用服务器响应时间
# $upstream_addr 后端服务器IP和端口号
log_format  main  '$remote_addr - [$time_local] "$request" '
                      '$status $body_bytes_sent '
                      '"$request_time" "$upstream_response_time" "$upstream_addr" "$request_body "';</code>

이 기계를 보면 Java 프로세스는 여전히 존재하지만 애플리케이션은 실제로 충돌이 발생했으며 실제 요청이 들어오지 않았습니다. 로드 밸런싱 중에 제거하면 문제가 즉시 완화됩니다.

이 컴퓨터는 실제로 중단되었습니다. 그런데 Nginx는 왜 그것을 인식하지 못했을까요? 추가 조사에 따르면 Nginx가 업스트림 서버를 호출할 때 기본 시간 제한은 60초입니다. 우리 애플리케이션의 응답 시간 요구 사항은 매우 높습니다. 따라서 1초를 초과하는 것은 의미가 없습니다. 따라서 nginx.conf 파일에서 기본 시간 제한을 수정하고 반환하면 됩니다. 1초를 초과했습니다. :

<code># time out settings  
proxy_connect_timeout 1s;  
proxy_send_timeout   1s;  
proxy_read_timeout   1s;</code>

运行一段时间后，问题已基本得到解决，不过还是会发现request_time超过1s达到5s的，但upstream_response_time都没有超时了，说明上面的参数已起作用。

版权声明：本文为博主原创文章，未经博主允许不得转载。

以上就介绍了Nginx 性能优化，包括了方面的内容，希望对PHP教程有兴趣的朋友有所帮助。