nginx与客户端默认是长连接,nginx与uwsgi的长连接需要设置keepalive和Http1.1,uwsgi与nginx的长连接需要设置http11-socket。
在设置了nginx upstream keepalive 为100的情况下。测试发现,长连接状态下,uwsgi进程没有充分忙碌,在压测的情形下,新用户请求到来,这个新请求会得到快速处理;短连接情况下,客户端得到的响应时间是平滑的,在压测的情形下,用户的新请求到来时,响应时间会稍慢,与压测的平均响应时间一致。
在我的例子中,长连接的耗时比短连接的耗时多。
1. nginx
1.1 客户端与nginx的长连接
-
keepalive_timeout
:客户端与nginx之间的长连接超时设置,当一个连接的最后一次数据传输至今超过了这个时间,那么当前连接就会被服务端主动关闭。 默认值60s,因此客户端与Nginx默认是长连接的。 -
keepalive_requests
也是客户端与Nginx的长连接设置,如果当前客户端与nginx之间的长连接上处理的请求数量超过设置值,那么当前长连接将会被关闭,qps不高的情况下使用默认值就行了,如果qps高达10000级别,最好把这个值调高一些。
1.2 nginx与server的长连接
nginx与server默认使用http1.0协议,这种连接是短连接,当请求到达时创建连接,当请求被处理完成后,立即关闭连接,想要使nginx与server之间使用长连接,需要设置http1.1协议,以及upstream中的最大空闲连接数。
http {
upstream app.my.com {
server 192.168.0.1:8080 ;
keepalive 300; // 这个很重要!
}
server {
location / {
proxy_http_version 1.1; // 这两个最好也设置
proxy_set_header Connection "";
}
}
-
keepalive
: 空闲长连接的最大数量。复用keepalive连接:free操作将当前连接缓存到cache队列中,并保存该连接对应后端的socket地址,get操作根据想要连接后端的socket地址,遍历查找cache队列,如果找到就使用先前缓存的长连接,未找到就重新建立新的连接。等到一些请求完成后,执行free操作,如果空闲的长连接数量超过了这个设置的值,nginx将会按照最近最少使用的原则关闭超过设置数量的连接。Nginx官方推荐keepalive的连接数应该配置的尽可能小
,以免出现被缓存的连接太多而造成新的连接请求过来时无法获取连接的情况(一个worker进程的总连接池是有限的)。nginx的长连接池,不是进程间共享的
。nginx upstream keepalive在缓存连接(free操作)和获取缓存的连接(get操作)时,只是查找匹配后端服务器的地址,而对前端没有任何感知。这就会造成一个问题,当用户1访问某站点后,会建立一个TCP连接,在后端web服务器没有关闭该连接之前,用户2同样访问该站点时,则不用建立TCP连接即可直接访问,也就是说nginx与后端的keepalive连接对前端来说是共享
的,这就造成一个性能问题,当几万个用户同时访问同一站点时,这几万个用户与nginx建立了几万条TCP连接,而nginx与后端服务器确有可能只有一条连接,这一条连接需要服务前端的几万个用户,这就大大的影响了系统的性能
!可以在释放对端连接时添加前端IP地址(获取其他标识信息)来标识前端,在获取连接遍历连接cache池时增加前端IP地址查找匹配,这样方能携带前端标识,避免多个前端共用一个后端连接从而影响性能的问题。 -
proxy_connect_timeout
:与后端服务器建立连接
的超时时间,我目前的理解是创建开始至创建连接成功的时间,Nginx官方提示这个超时一般不要大于75秒。 -
proxy_send_timeout
:默认60s,定义向后端服务器传输请求的超时。这是向server发送相邻的两个请求之间的最长时间间隔。如果后端服务器在超时时间段内没有接收到任何数据,连接将被关闭。 -
proxy_read_timeout
:默认60s,定义从后端服务器读取响应的超时。此超时是指相邻两次读操作之间的最长时间间隔,而不是整个响应传输完成的最长时间。如果后端服务器在超时时间段内没有返回任何数据,连接将被关闭。如果后端处理请求的耗时较久,需要把这个设置项设置得大一些。
2. uwsgi
-
http11-socket
:使用HTTP 1.1 (Keep-Alive)协议绑定到指定UNIX/TCP socket上 -
processes
: 一般设置为cpu核数的两倍,不是越大越好。我曾经以为设置大了,并发性能会更好,将该值设置为80,5000个请求在300并发的情况下最后三个左右的响应总是超时,降低该值后不再出现超时。