摘要：
需要在Nginx的配置文件中开启Keep-Alive连接。可以在块或块中添加以下配置:http{keepalive_timeout65;keepalive_requests100;... 需要在 Nginx 的配置文件中开启 Keep-Alive 连接。可以在块或块中添加以下配置:
http {keepalive_timeout 65;keepalive_requests 100;# 其他配置}
keepalive_timeout
指定 Keep-Alive 连接的超时时间,单位为秒。
keepalive_requests
则设置一个 Keep-Alive 连接上可以处理的最大请求数。
合理调整
keepalive_timeout
的值可以进一步优化 Keep-Alive 连接的性能。一般来说,较短的超时时间可以减少连接的数量,但会增加建立新连接的开销。相反,较长的超时时间可以减少建立新连接的开销,但会增加连接的数量。
需要根据您的具体应用场景和负载情况来选择合适的超时时间。例如,您的网站访问量较高,可以适当降低
keepalive_timeout
的值,以减少连接数量;反之,您的网站访问量较低,可以适当增加
keepalive_timeout
的值,以减少建立新连接的开销。
另一个需要考虑的参数是
keepalive_requests
。这个参数设置一个 Keep-Alive 连接上可以处理的最大请求数。当一个 Keep-Alive 连接处理完指定数量的请求后,Nginx 会自动关闭该连接,从而防止连接占用过多的服务器资源。
通常情况下,将
keepalive_requests
设置为 100 左右是一个合理的选择。但是,您的应用程序需要频繁建立新连接,可以考虑将该值适当降低,以减少连接的数量。相反,您的应用程序对于连接的建立和关闭比较敏感,可以适当增加该值,以减少建立新连接的开销。
除上述 Keep-Alive 连接的优化措施,您还可以结合其他优化手段,进一步提高网站的性能。例如:
通过综合运用这些优化措施,您可以进一步提高网站的整体性能。
在优化 Keep-Alive 连接时,需要进行充分的测试和监控,确保优化措施能够达到预期的效果。您可以使用压力测试工具,如或,来模拟大量并发请求,并观察网站的响应时间和吞吐量。您也可以使用监控工具,如
Nginx 状态模块
或
Prometheus
,来实时监控 Nginx 的性能指标,及时发现和解决问题。
通过以上几个步骤,您就可以有效地优化 Nginx 中的 Keep-Alive 连接,提高网站的性能和响应速度。当然,具体的优化策略还需要根据您的应用场景和负载情况进行调整和测试,以找到最佳的配置方案。
您好，我的论坛linux nginx服务器 速度有些慢，请问有优化方法吗
一、编译安装过程优化1.减小Nginx编译后的文件大小在编译Nginx时，默认以debug模式进行，而在debug模式下会插入很多跟踪和ASSERT之类的信息，编译完成后，一个Nginx要有好几兆字节。 在编译前取消Nginx的debug模式，编译完成后Nginx只有几百千字节，因此可以在编译之前，修改相关源码，取消debug模式，具体方法如下：在Nginx源码文件被解压后，找到源码目录下的auto/cc/gcc文件，在其中找到如下几行：# debugCFLAGS=”$CFLAGS -g”注释掉或删掉这两行，即可取消debug模式。 2.为特定的CPU指定CPU类型编译优化在编译Nginx时，默认的GCC编译参数是“-O”，要优化GCC编译，可以使用以下两个参数：--with-cc-opt=-O3--with-cpu-opt=CPU#为特定的 CPU 编译，有效的值包括：pentium, pentiumpro, pentium3, pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64要确定CPU类型，可以通过如下命令: [root@localhost home]#cat /proc/cpuinfo | grep model name二、利用TCMalloc优化Nginx的性能TCMalloc的全称为Thread-Caching Malloc，是谷歌开发的开源工具“google-perftools”中的一个成员。 与标准的glibc库的malloc相比，TCMalloc库在内存分配效率和速度上要高很多，这在很大程度上提高了服务器在高并发情况下的性能，从而降低系统负载。 下面简单介绍如何为Nginx添加TCMalloc库支持。 要安装TCMalloc库，需要安装libunwind（32位操作系统不需要安装）和google-perftools两个软件包，libunwind库为基于64位CPU和操作系统的程序提供了基本函数调用链和函数调用寄存器功能。 下面介绍利用TCMalloc优化Nginx的具体操作过程：1.安装libunwind库可以从下载相应的libunwind版本，这里下载的是，安装过程如下： [root@localhost home]#tar zxvf [root@localhost home]# cd libunwind-0.99-alpha/[root@localhost libunwind-0.99-alpha]#CFLAGS=-fPIC ./configure[root@localhost libunwind-0.99-alpha]#make CFLAGS=-fPIC[root@localhost libunwind-0.99-alpha]#make CFLAGS=-fPIC install2.安装google-perftools可以从下载相应的google-perftools版本，这里下载的是，安装过程如下： [root@localhost home]#tar zxvf [root@localhost home]#cd google-perftools-1.8/[root@localhost google-perftools-1.8]# ./configure[root@localhost google-perftools-1.8]#make && make install[root@localhost google-perftools-1.8]#echo /usr/local/lib > /etc/.d/usr_local_[root@localhost google-perftools-1.8]# ldconfig至此，google-perftools安装完成。 3.重新编译Nginx为了使Nginx支持google-perftools，需要在安装过程中添加“–with-google_perftools_module”选项重新编译Nginx，安装代码如下： [root@localhostnginx-0.7.65]#./configure \>--with-google_perftools_module --with-http_stub_status_module--prefix=/opt/nginx[root@localhost nginx-0.7.65]#make[root@localhost nginx-0.7.65]#make install到这里Nginx安装完成。 4.为google-perftools添加线程目录创建一个线程目录，这里将文件放在/tmp/tcmalloc下，操作如下： [root@localhost home]#mkdir /tmp/tcmalloc[root@localhost home]#chmod 0777 /tmp/tcmalloc5.修改Nginx主配置文件修改文件，在pid这行的下面添加如下代码： #pidlogs/;google_perftools_profiles /tmp/tcmalloc;接着，重启Nginx，完成google-perftools的加载。 6.验证运行状态为了验证google-perftools已经正常加载，通过如下命令查看： [root@ localhost home]# lsof -n | grep tcmallocnginx2395 nobody 9wREG8,8 /tmp/tcmalloc.2395nginx2396 nobody 11w REG 8,8 /tmp/tcmalloc.2396nginx2397 nobody 13w REG8,/tmp/tcmalloc.2397nginx 2398 nobody15w REG8,8 /tmp/tcmalloc.2398由于在Nginx配置文件中，设置worker_processes的值为4，因此开启了4个Nginx线程，每个线程会有一行记录。 每个线程文件后面的数字值就是启动的Nginx的PID值。 至此，利用TCMalloc优化Nginx的操作完成。 三、Nginx内核参数优化内核参数的优化，主要是在Linux系统中针对Nginx应用而进行的系统内核参数优化，常见的优化参数值如下。 下面给出一个优化实例以供参考_max_tw_buckets = 6000 _local_port_range = 1024 _tw_recycle = 1 _tw_reuse = 1 _syncookies = 1 = _max_backlog = _max_orphans = _max_syn_backlog = _synack_retries = 1 _syn_retries = 1 _fin_timeout = 1 _keepalive_time = 30 将上面的内核参数值加入/etc/文件中，然后执行如下命令使之生效：[root@ localhost home]#/sbin/sysctl -p下面是对实例中选项的含义进行介绍： _max_tw_buckets参数用来设定timewait的数量，默认是，这里设为6000。 _local_port_range选项用来设定允许系统打开的端口范围。 _tw_recycle选项用于设置启用timewait快速回收。 _tw_reuse选项用于设置开启重用，允许将TIME-WAIT sockets重新用于新的TCP连接。 _syncookies选项用于设置开启SYN Cookies，当出现SYN等待队列溢出时，启用cookies进行处理。 选项默认值是128， 这个参数用于调节系统同时发起的tcp连接数，在高并发的请求中，默认的值可能会导致链接超时或者重传，因此，需要结合并发请求数来调节此值。 _max_backlog选项表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许发送到队列的数据包的最大数目。 _max_orphans选项用于设定系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。 如果超过这个数字，孤立连接将立即被复位并打印出警告信息。 这个限制只是为了防止简单的DoS攻击。 不能过分依靠这个限制甚至人为减小这个值，更多的情况是增加这个值。 _max_syn_backlog选项用于记录那些尚未收到客户端确认信息的连接请求的最大值。 对于有128MB内存的系统而言，此参数的默认值是1024，对小内存的系统则是128。 _synack_retries参数的值决定了内核放弃连接之前发送SYN+ACK包的数量。 _syn_retries选项表示在内核放弃建立连接之前发送SYN包的数量。 _fin_timeout选项决定了套接字保持在FIN-WAIT-2状态的时间。 默认值是60秒。 正确设置这个值非常重要，有时候即使一个负载很小的Web服务器，也会出现因为大量的死套接字而产生内存溢出的风险。 _keepalive_time选项表示当keepalive启用的时候，TCP发送keepalive消息的频度。 默认值是2（单位是小时）。
Nginx篇05——http长连接和keeplive
nginx中http模块使用http长连接的相关配置（主要是keepalive指令）和http长连接的原理解释。
连接管理是一个 HTTP 的关键话题：打开和保持连接在很大程度上影响着网站和 Web 应用程序的性能。 在 HTTP/1.x 里有多种模型：短连接, 长连接, 和 HTTP 流水线。 在解释这三种模型之前，我们需要先明确一些前提知识：
接下来我们开始解释。
在早期，HTTP 使用一个简单的模型来处理这样的连接。 这些连接的生命周期是短暂的：每发起一个请求时都会创建一个新的连接，并在收到应答时立即关闭。 这就是类似上面说的三次握手，在互联网发展的早期一个网页的资源并没有现在这么多，很多可能只是一个简单的静态页面而已，所以这样的模型显然很OK。 客户端获取完所需资源之后，就断开连接，不再占用服务器的资源。
HTTP 短连接模型是最早期的模型，也是HTTP/1.0 的默认模型。 每一个 HTTP 请求都由它自己独立的连接完成；这意味着发起每一个 HTTP 请求之前都会有一次 TCP 握手，而且是连续不断的。 实际上，TCP 协议握手本身就是耗费时间的，所以 TCP 可以保持更多的热连接来适应负载。 短连接破坏了 TCP 具备的能力，新的冷连接降低了其性能。
后来，网页需要请求的资源越来越多，短连接模型显然已经十分吃力了。 因为短连接有两个比较大的问题：创建新连接耗费的时间尤为明显（三次握手很耗费时间），另外 TCP 连接的性能只有在该连接被使用一段时间后(热连接)才能得到改善。 因此在HTTP/1.1中引入了长连接模型和流水线模型。
一个长连接会保持一段时间，重复用于发送一系列请求，节省了新建 TCP 连接握手的时间，还可以利用 TCP 的性能增强能力。 当然这个连接也不会一直保留着：连接在空闲一段时间后会被关闭(服务器可以使用 Keep-Alive 协议头来指定一个最小的连接保持时间)。
长连接也还是有缺点的；也就是前面提到的资源占用问题，就算是在空闲状态，它还是会消耗服务器资源，也更容易被DDoS攻击。 本质上长连接是因为不断地三次握手建立连接消耗的资源要大于维持连接所需要的资源才使用的 ，如果服务器处于高负载时段或者被DDoS，可以使用非长连接，即尽快关闭那些空闲的连接，也能对性能有所提升。
流水线模型的实现要复杂很多，而已效果也并不是特别好，主要还要考虑到各种兼容性，所以默认是不启用这个流水线模型的，而在HTTP/2中，流水线已经被更好的算法给代替，如 multiplexing 。
默认情况下，HTTP 请求是按顺序发出的。 下一个请求只有在当前请求收到应答过后才会被发出。 由于会受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。 流水线是在同一条长连接上发出连续的请求，而不用等待应答返回。 这样可以避免连接延迟。 理论上讲，性能还会因为两个 HTTP 请求有可能被打包到一个 TCP 消息包中而得到提升。 就算 HTTP 请求不断的继续，尺寸会增加，但设置 TCP 的MSS(Maximum Segment Size)选项，仍然足够包含一系列简单的请求。
并不是所有类型的 HTTP 请求都能用到流水线：只有idempotent 方式，比如GET 、 HEAD 、 PUT 和DELETE 能够被安全的重试：因为有故障发生时，流水线的内容要能被轻易的重试，即出现了问题重试的成本要尽可能低，否则还不如使用长连接模型。
正确的实现流水线是复杂的：传输中的资源大小，多少有效的RTT会被用到，还有有效带宽，流水线带来的改善有多大的影响范围。 不知道这些的话，重要的消息可能被延迟到不重要的消息后面。 这个重要性的概念甚至会演变为影响到页面布局！因此 HTTP 流水线在大多数情况下带来的改善并不明显。 此外，流水线受制于 HOL 问题。
我们还是使用上面的例子来进行解释，这次的握手请求就变了，A一次向B发出了三个请求：
最后这里补充一张图片来对比三种模型之间的差别：
了解了上面的原理之后，Nginx中的keepalive指令我们就非常好理解了，相关的指令主要有三个，我们逐个进行解释：
在upstream模块中配置，启用连接到upstream中的服务器的缓存， connections 参数的主要作用是设定每个Nginx的 单个worker进程（each worker process） 对于upstream中的server的最大空闲连接数，当超过该数字的时候，会关闭使用得最少的连接。
需要注意的是，keepalive指令并不会限制Nginx的 所有worker 进程能开启的连接到upstream服务器中的 连接总数（total number） 。 也就是如果设得太大了，会导致过多的空闲连接占满了upstream中的server资源，导致新的连接无法建立，因此这个数值的设定需要根据worker进程数量来调整。
keepalive_requests 设定可以通过一个连接（connection）发送的请求（request）数量，超过最大请求数量之后，该连接会被关闭。 为了释放每个连接的内存分配，定期关闭连接是很有必要的。 因此，不建议将 keepalive_requests 设定过大，否则可能会导致过高的内存占用。
设定连接超时时间，在此设定的时间内，client与upstream中的server的空闲keepalive连接将保持打开状态（open）。 此外，虽然官方文档说的默认值是60s，但是1.17.9版本的Nginx在安装之后配置文件上面设定的是65s。
nginx timeout配置
在Nginx中，超时配置是关键性能调优参数。主要涉及以下几个方面：
这些超时设置需要根据实际需求和服务器负载进行调整，以平衡性能和数据完整性。 Nginx的默认值通常是保守的，可以根据应用的具体情况适当地进行个性化配置。