大量的Nginx / uwsgi服务内容会因keepalive_timeout秒而挂起

时间:2013-10-30 22:48:37

标签: python django nginx uwsgi

我使用类似的视图通过django 1.5.1提供动态生成的pdf:

pdf = generate_pdf()
response = HttpResponse(pdf, mimetype="application/pdf")
response['Content-Disposition'] = 'attachment; filename=1234_2013_10_30.pdf'
return response

在开发服务器上100%的时间工作。但是,我正在使用uwsgi版本1.9.18.2和nginx版本1.1.19并获得以下行为:

$ curl -v -o test.out "http://localhost/demo/awc.pdf?submissionType=addition&permit=1234"
...
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET /demo/awc.pdf?submissionType=addition&permit=1234 HTTP/1.1
> User-Agent: curl/7.21.2 (Windows) libcurl/7.21.2 OpenSSL/1.0.0a zlib/1.2.3
> Host: localhost
> Accept: */*
>
  0     0    0     0    0     0      0      0 --:--:--  0:00:10 --:--:--     0

< HTTP/1.1 200 OK
< Server: nginx/1.1.19
< Date: Wed, 30 Oct 2013 22:14:23 GMT
< Content-Type: application/pdf
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Language, Cookie
< Content-Language: en-us
< Content-Disposition: attachment; filename=1234_2013_10_30.pdf
<
{ [data not shown]
100 2313k    0 2313k    0     0  270k       0 --:--:--  0:00:12 --:--:--     0
.....
100 2313k    0 2313k    0     0  77452      0 --:--:--  0:00:30 --:--:--     0* transfer closed with outstanding read data remaining
100 2313k    0 2313k    0     0  75753      0 --:--:--  0:00:31 --:--:--     0* Closing connection #0

curl: (18) transfer closed with outstanding read data remaining

总之,客户端在10秒内获得响应,在~2秒内下载所有数据,然后再挂起18秒。

并非巧合,我的nginx配置指定keepalive_timeout 20s;。等待keepalive_timeout秒后, 内容完全没问题。 我可以通过将keepalive_timeout设置为零来“解决”这个问题,但这不是一个真正可行的解决方案。

当内容很小(小于1MB)时,问题莫名其妙地消失了。

> GET "http://localhost/demo/awc.pdf?submissionType=addition&permit=5678" HTTP/1.1
> User-Agent: curl/7.21.2 (Windows) libcurl/7.21.2 OpenSSL/1.0.0a zlib/1.2.3
> Host: localhost
> Accept: */*
>
  0     0    0     0    0     0      0      0 --:--:--  0:00:04 --:--:--     0< HTTP/1.1 200 OK
< Server: nginx/1.1.19
< Date: Wed, 30 Oct 2013 22:39:12 GMT
< Content-Type: application/pdf
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Language, Cookie
< Content-Language: en-us
< Content-Disposition: attachment; filename=1234_2013_10_30.pdf
<
{ [data not shown]
100  906k    0  906k    0     0   190k      0 --:--:--  0:00:04 --:--:--  246k* Connection #0 to host localhost left intact 

我猜测它与分块编码或缺少内容长度标题有关,但我似乎无法找到神奇的咒语。有什么想法吗?

2 个答案:

答案 0 :(得分:1)

仍然不确定为什么会出现原始问题,但找到了一个不错的解决方法:

在nginx配置中禁用分块传输编码似乎可以避免此问题。

location / {
    uwsgi_pass unix:///var/run/uwsgi/app/socket;
    include uwsgi_params;
    # keepalive_timeout 0;
    chunked_transfer_encoding off;
}

答案 1 :(得分:0)

我遇到了同样的问题,但它只发生在动态生成的内容上。我在nginx 1.5.8和ubuntu 12.04LTS上运行fastcgi_pass到php-fpm - 而且我的keepalive_timeout也导致了挂起!

我认为keepalive_timeouts只用于(应该用于)静态内容 - 但我正在欺骗我的动态javascript文件(js.php),因为它是静态的,所以keepalive超时正在应用?

如果我能找到一个永久的解决方案而不是这个解释......我会发布它。 Ah yes, perhaps this就是答案,因为它说在nginx.conf文件中指定了这个 -

fastcgi_keep_conn on;

我仍然把keepalive_timeout留给了1秒钟,但是在接受的答案中提供的解决方案是有道理的 - 我的动态文件被传递给fastcgi但是fastcgi - here's also an official nginx doc没有保留keepalive连接。

  

默认情况下,FastCGI服务器将在发送响应后立即关闭连接。但是,当此伪指令设置为on时,nginx将指示FastCGI服务器保持连接打开。特别是,这对于与FastCGI服务器的keepalive连接起作用是必要的。