关于 Nginx upstream keepalive 的说明

模块是 HttpUpstreamModule,配置的一个例子:

[shell]upstream http_backend {
server 127.0.0.1:8080;

keepalive 16;
}
server {

location /http/ {
proxy_pass http://http_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";

}
}[/shell]

 

有几点要说明:

1. 默认情况下 Nginx 访问后端都是用的短连接(HTTP1.0),一个请求来了,Nginx 新开一个端口和后端建立连接,请求结束连接回收。如果像上面的配置一样设置了长连接,Nginx 会接受客户端的请求,处理完成之后 Nginx 会「继续保持和后端的长连接」,如果并发请求超过了 keepalive 指定的最大连接数,Nginx 会启动新的连接 来转发请求,新连接在请求完毕后关闭,而且新建立的连接是长连接,这可能会造成额外的问题,最后再说。

2. keepalive 指定的 数值 是 Nginx 每个 worker  连接后端的最大长连接数,而不是整个 Nginx 的。 而且这里的后端指的是「所有的后端」,而不是每一个后端(已验证)。

3. 在官网上  可以看到 还有一个 single 参数,说实话我没懂什么意思,但是它已经被废弃了,看这里

4. HttpUpstreamModule 模块里面还有一共指令:least_conn,解释如下:

Specifies that a group should use a load balancing method where a request is passed to the server with the least number of active connections, taking into account weights of servers. If there are several such servers, they are tried in turn using a weighted round-robin balancing method.

翻译:

指定服务器组的负载均衡方法,根据其权重值,将请求发送到「活跃连接数最少」的那台服务器。 如果这样的服务器有多台,那就采取有权重的轮转法进行尝试。

使用这个指令的时候后端服务器的连接数好像会变的非常少,很奇怪,我还没亲自测过,待确认。

 

最后再说一下第 1 点,先说一个现象,我发现当 keepalive 设置小的时候,比如1,那么并发请求上去之后 Nginx 会出现大量的 TIME_WAIT,而如果把 keepalive 关掉(proxy_http_version 1.1 和 proxy_set_header Connection “” 指令也去掉),那么 TIME_WAIT 就会出现在后端服务器了,后端用的是 tornado,相信 jetty 和 tomcat 也是一样。

这个现象是怎么产生的呢,做一个测试。

命令:ab -n 100 -c 5 http://pxe1.hy01/

pxe1.hy01 (Nginx,上面配置了长连接,ip: 10.0.31.84) ,它会转到 pxe0.hy01 的 8888 端口(tornado,ip: 10.0.11.12)

测试的时候在 pxe1.hy01 执行抓包命令:

# tcpdump -i em2 -A host 10.0.11.12 -n

看到:

00:22:53.252039 IP 10.0.31.84.53915 > 10.0.11.12.ddi-tcp-1: Flags [P.], seq 81:161, ack 275, win 123, length 80
@.@.].
..T
…..”…p%8|..P..{>…GET / HTTP/1.1
Host: http_backend
User-Agent: ApacheBench/2.3
Accept: */*

但是如果把 pxe1.hy01 的长连接设置都去掉的话,抓包如下:

00:23:58.111974 IP 10.0.31.84.54051 > 10.0.11.12.ddi-tcp-1: Flags [P.], seq 1:100, ack 1, win 115, length 99
E…..@.@.Z=
..T
….#”…O…SUP..s>…GET / HTTP/1.0
Host: http_backend
Connection: close
User-Agent: ApacheBench/2.3
Accept: */*

那么上面出现的现象就好解释了,是这样:

Nginx 和后端的长连接不够用时 Nginx 会新建连接来处理新的请求,而我们的配置已经配置死了 HTTP1.1,建立连接后,后端认为是「长连接」而不会主动关闭连接(一般有个空闲超时),关闭连接由 Nginx 来做了,所以 Nginx 会出现大量的 TIME_WAIT。

而默认情况下,Nginx 用 HTTP1.0 请求后端,后端处理完成后就主动关闭连接,所以 TIME_WAIT 在后端。

那么现在有新的问题了,如果开启了长连接,而长连接又大量不够用,此时 Nginx 存在的 TIME_WAIT 可能会大量占用端口,导致端口用尽,如果用尽,后果很严重。

所以,「慎用 Nginx 的 长连接」。

 

长连接下LVS和NGINX对HTTP请求的处理是否使用负载均衡

今天突然想对长连接下LVS和NGINX是怎么做负载均衡的,会不会转发到同一个后端机器,so 测试一下。

Client —> LVS —> NGINX —> APP

测试点

在持久连接(长连接)的情况下,http的请求会保持一条路径么(同一个LVS、NGINX、APP)?

准备,分别对 NGINX 和 LVS 测试,测试路径如下:

1. NGINX —> APP

2. LVS —> APP

测试一

测试代码(http1.1默认支持keepalive,不用指定即是长连接)

[python]#!/usr/bin/python
#-*- coding: utf-8 -*-

import urllib
import httplib
import time

def keepalive(t):
url = "60.28.208.8"

conn = httplib.HTTPConnection(url)

conn.request("GET", "/test")
ret = conn.getresponse()
print ret.status, ret.reason
data = ret.read()

time.sleep(10)

conn.request("GET", "/test")
ret = conn.getresponse()
print ret.status, ret.reason
data = ret.read()

conn.close()
[/python]

NGINX 配置文件

upstream test-nodes {
    server pxe0.hy01:8888;
    server pxe2.hy01:8888;
}

server {
    listen 80;
    server_name 60.28.208.8;
    access_log /home/work/nginx/logs/test_wandoujia.access.log main;
    error_log /home/work/nginx/logs/test_wandoujia.error.log;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://test-nodes;
    }
}

其中,NGINX的 keepalive_timeout 设置为30,保证 在我们sleep 的时间内 连接不断。

跑脚本发现,第一次http请求落在 test0 上,第二次落在 test1 上,说明在 http持久连接下 NGINX 依然会 选择不同的后端进行 负载均衡。

测试二

1. persistence_timeout 设置为0,syn_proxy 关闭的情况下,两次请求 落到同一个后端。

2. persistence_timeout 设置为0,syn_proxy 打开的情况下,两次请求 落到同一个后端。

3. persistence_timeout 设置不为0,syn_proxy 关闭的情况下,两次请求 落到同一个后端。

4. persistence_timeout 设置不为0,syn_proxy 打开的情况下,两次请求 落到同一个后端。

看起来和 syn_proxy 没关系,可以忽略syn_proxy 了。

可以看出,在http持久连接下,LVS 会把 请求转给同一个后端。

另外,我也验证了,如果是多个单独的HTTP请求(请求完就关闭连接),LVS 会负载均衡到 两个后端。

总结

持久连接下,LVS会把请求转发到同一个后端,而NGINX 会转发到不同的后端。

那么即使在长连接下,NGINX也会对请求做负载均衡,这种情况会造成SESSION失效,所以对和账号相关的服务,需要做会话保持,还好 像LVS、NGINX 和HAPROXY 这些负载均衡器都有保持会话的方法。