nginx 프로세스 수는 CPU 수에 따라 지정하는 것이 좋으며 일반적으로 CPU 수의 배수입니다.
각 프로세스에 CPU를 할당합니다. 위의 예에서는 8개의 프로세스가 8개의 CPU에 할당됩니다. 물론 여러 개의 CPU에 하나의 프로세스를 할당할 수도 있습니다.
이 명령은 nginx 프로세스에서 열린 최대 파일 설명자 수를 나타냅니다. 이론적 값은 최대 열린 파일 수(ulimit -n)를 nginx 프로세스 수로 나눈 값이어야 합니다. nginx 할당 요청은 그렇게 균일하지 않으므로 ulimit -n 값과 일관성을 유지하는 것이 좋습니다.
epoll의 I/O 모델을 사용하면 당연합니다.
프로세스당 허용되는 최대 연결 수는 이론적으로 nginx 서버당 최대 연결 수는 Worker_processes*worker_connections입니다.
연결 유지 시간 초과.
클라이언트 요청 헤더의 버퍼 크기입니다. 이는 시스템 페이징 크기에 따라 설정될 수 있습니다. 일반적으로 요청의 헤더 크기는 1k를 초과하지 않지만 일반 시스템 페이징이 더 크기 때문입니다. 1k보다 크므로 페이징 크기로 설정됩니다. 페이징 크기는 getconf PAGESIZE 명령을 사용하여 얻을 수 있습니다.
이것은 열린 파일에 대한 캐시를 지정합니다. 기본적으로 활성화되지 않습니다. 최대는 캐시 수를 지정하는 것이 좋습니다. 캐시가 삭제되기 전에 파일이 요청되지 않았습니다.
캐시된 유효한 정보를 얼마나 자주 확인하는지를 나타냅니다.
open_file_cache 지시문의 비활성 매개변수 동안 파일이 사용되는 최소 횟수입니다. 이 숫자를 초과하면 위의 예와 같이 파일 설명자가 항상 캐시에서 열립니다. 비활성 시간 내에 파일이 있습니다. 사용하지 않으면 삭제됩니다.
대기 시간 수, 기본값은 180000입니다.
시스템에서 열 수 있는 포트 범위입니다.
시간 대기 빠른 재활용을 활성화합니다.
재사용을 활성화합니다. 새로운 TCP 연결에 TIME-WAIT 소켓을 재사용할 수 있습니다.
SYN 쿠키를 활성화합니다. SYN 대기 대기열이 오버플로되면 쿠키를 활성화하여 이를 처리합니다.
웹 애플리케이션의 수신 기능 백로그는 커널 매개변수의 net.core.somaxconn을 기본적으로 128로 제한하고 nginx에서 정의한 NGX_LISTEN_BACKLOG의 기본값은 511이므로 필요합니다. 이 값을 조정합니다.
각 네트워크 인터페이스가 커널이 처리할 수 있는 것보다 더 빠르게 패킷을 수신할 때 대기열에 들어갈 수 있는 최대 패킷 수입니다.
사용자 파일 핸들과 연결되지 않은 시스템의 최대 TCP 소켓 수입니다. 이 숫자를 초과하면 고아 연결이 즉시 재설정되고 경고 메시지가 인쇄됩니다. 이 제한은 단순한 DoS 공격을 방지하기 위한 것입니다. 이 값에 너무 많이 의존하거나 인위적으로 이 값을 늘려야 합니다(메모리를 추가하는 경우).
아직 클라이언트로부터 확인을 받지 못한 기록된 연결 요청의 최대 수입니다. 메모리가 128M인 시스템의 경우 기본값은 1024이고, 메모리가 작은 시스템의 경우 기본값은 128입니다.
타임 스탬프를 사용하면 일련번호 줄바꿈을 피할 수 있습니다. 1Gbps 링크는 확실히 이전에 사용되었던 시퀀스 번호를 만나게 됩니다. 타임스탬프를 사용하면 커널이 이러한 "비정상적인" 패킷을 허용할 수 있습니다. 여기서는 꺼야 합니다.
피어에 대한 연결을 열려면 커널은 이전 SYN에 대한 응답으로 ACK와 함께 SYN을 보내야 합니다. 이른바 삼자악수 중 두 번째 악수다. 이 설정은 연결을 포기하기 전에 커널이 보내는 SYN+ACK 패킷 수를 결정합니다.
커널이 연결 설정을 포기하기 전에 전송된 SYN 패킷 수입니다.
로컬 끝에서 소켓 닫기를 요청하는 경우 이 매개변수는 FIN-WAIT-2 상태를 유지하는 기간을 결정합니다. 피어는 오류를 범하고 연결을 닫지 않거나 예기치 않게 충돌할 수도 있습니다. 기본값은 60초입니다. 2.2 커널의 일반적인 값은 180초입니다. 그러나 귀하의 컴퓨터가 로드가 적은 웹 서버라도 많은 수의 데드 소켓으로 인해 메모리 오버플로가 발생할 위험이 있다는 점을 기억하십시오. 2는 최대 1.5K의 메모리만 먹을 수 있기 때문에 FIN-WAIT-1보다 덜 위험하지만 생존 기간은 더 깁니다.
킵얼라이브가 활성화되면 TCP가 킵얼라이브 메시지를 보내는 빈도입니다. 기본값은 2시간입니다.
这个指令为FastCGI缓存指定一个路径,目录结构等级,关键字区域存储时间和非活动删除时间。
指定连接到后端FastCGI的超时时间。
向FastCGI传送请求的超时时间,这个值是指已经完成两次握手后向FastCGI传送请求的超时时间。
接收FastCGI应答的超时时间,这个值是指已经完成两次握手后接收FastCGI应答的超时时间。
指定读取FastCGI应答第一部分需要用多大的缓冲区,这里可以设置为fastcgi_buffers指令指定的缓冲区大小,上面的指令指定它将使用1 个16k的缓冲区去读取应答的第一部分,即应答头,其实这个应答头一般情况下都很小(不会超过1k),但是你如果在fastcgi_buffers指令中 指定了缓冲区的大小,那么它也会分配一个fastcgi_buffers指定的缓冲区大小去缓存。
指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答,如上所示,如果一个php脚本所产生的页面大小为256k,则会为其分配16个16k的缓 冲区来缓存,如果大于256k,增大于256k的部分会缓存到fastcgi_temp指定的路径中,当然这对服务器负载来说是不明智的方案,因为内存中 处理数据速度要快于硬盘,通常这个值的设置应该选择一个你的站点中的php脚本所产生的页面大小的中间值,比如你的站点大部分脚本所产生的页面大小为 256k就可以把这个值设置为16 16k,或者4 64k 或者64 4k,但很显然,后两种并不是好的设置方法,因为如果产生的页面只有32k,如果用4 64k它会分配1个64k的缓冲区去缓存,而如果使用64 4k它会分配8个4k的缓冲区去缓存,而如果使用16 16k则它会分配2个16k去缓存页面,这样看起来似乎更加合理。
这个指令我也不知道是做什么用,只知道默认值是fastcgi_buffers的两倍。
在写入fastcgi_temp_path时将用多大的数据块,默认值是fastcgi_buffers的两倍。
开启FastCGI缓存并且为其制定一个名称。个人感觉开启缓存非常有用,可以有效降低CPU负载,并且防止502错误。但是这个缓存会引起很多问题,因为它缓存的是动态页面。具体使用还需根据自己的需求。
为指定的应答代码指定缓存时间,如上例中将200,302应答缓存一小时,301应答缓存1天,其他为1分钟。
缓存在fastcgi_cache_path指令inactive参数值时间内的最少使用次数,如上例,如果在5分钟内某文件1次也没有被使用,那么这个文件将被移除。
不知道这个参数的作用,猜想应该是让nginx知道哪些类型的缓存是没用的。 以上为nginx中FastCGI相关参数,另外,FastCGI自身也有一些配置需要进行优化,如果你使用php-fpm来管理FastCGI,可以修改配置文件中的以下值:
同时处理的并发请求数,即它将开启最多60个子线程来处理并发连接。
最多打开文件数。
每个进程在重置之前能够执行的最多请求数。
以上就介绍了nginx--优化配置示例,包括了方面的内容,希望对PHP教程有兴趣的朋友有所帮助。