keepalive_timeout参数是一个请求完成之后还要保持连接多久，不是请求时间多久，目的是保持长连接，减少创建连接过程给系统带来的性能损耗，类似于线程池，数据库连接池。
现象说明：
在服务器上部署了一套后台环境，使用的是nginx反向代理tomcat架构，在后台里上传一个70M的视频文件，上传到一半就失效了！
原因是nginx配置里限制了上传文件的大小
client_max_body_size：这个参数的设置限制了上传文件的大小，可以在http、server、location三个区域里配置
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 | [root@dev-huanqiu ~]# cat /Data/app/nginx/conf/nginx.conf..............http { include mime.types; default_type application/octet-stream; charset utf-8; ####### ## http setting ####### sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 100; #这个参数表示http连接超时时间，默认是65s。要是上传文件比较大，在规定时间内没有上传完成，就会自动断开连接！所以适当调大这个时间。 fastcgi_connect_timeout 6000; fastcgi_send_timeout 6000; fastcgi_read_timeout 6000; fastcgi_buffer_size 256k; fastcgi_buffers 8 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; ## client_header_timeout 120s; #调大点 client_body_timeout 120s; #调大点 client_max_body_size 100m; #主要是这个参数，限制了上传文件大大小 client_body_buffer_size 256k; ## support more than 15 test environments server_names_hash_max_size 512; server_names_hash_bucket_size 128; gzip on; gzip_min_length 1k; gzip_buffers 4 16k; gzip_http_version 1.1; gzip_comp_level 9; gzip_types text/plain application/x-javascript text/css application/xml text/javascript application/x-httpd-php; gzip_vary on;[root@dev-huanqiu ~]# cat /Data/app/nginx/conf/vhosts/admin.wangshibo.confserver { listen 80; server_name admin.wangshibo.com; #if ($http_x_forwarded_for !~ ^(14.165.97.54|123.110.186.128|123.110.186.68)) { # rewrite ^.*$ /maintence.php last; #} access_log /var/log/wangshibo.log main; location / { proxy_pass http://127.0.0.1:8484/; proxy_connect_timeout 300; #这三个超时时间适量调大点 proxy_send_timeout 600; proxy_read_timeout 600; proxy_set_header X-Real-IP $remote_addr; # 获取客户端真实IP proxy_set_header REMOTE-HOST $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 获取代理者的真实ip proxy_set_header X-Forwarded-Scheme $scheme; # 解决getScheme，isSecure，sendRedirect proxy_buffer_size 32k; proxy_buffers 32 256k; proxy_busy_buffers_size 512k; proxy_temp_file_write_size 512k; } location /static/video { root /Data/app/tomcat-7-admin-wls/static/video; } } ##end server |
另外，tomcat的server.xml配置文件中的connectionTimeout超时时间也可以适当调大点，默认是20000，可以改成60000.
Nginx代理请求超时时间
可以参考：http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout
====================================================================================
注意一点：
keepalive_timeout这个是nginx里关于http连接超时的一个设置，功能是使客户端到服务器端的连接在设定的时间内持续有效，当出现对服务器的后继请求时，该功能避免了建立或者重新建立连接。切记这个参数也不能设置过大！
因为客户端接口访问其实是一个比较快速的过程，访问完成了就不需要继续使用http连接了，如果将该参数值设置过大，就会导致接口访问完成后http连接并没有被释放掉，所以导致连接数越来越大，最终nginx崩溃！
如果http连接数过大时，超过了nginx里对于连接数的配置，比如“worker_connections 65535”，那么对应的nginx报错日志里会有信息：（socket() failed (24: Too many open files) while connecting to upstream）时不时的出现。
所以，要严格控制keepalive_timeout超时时间的设置，调大点的话，就会导致许多无效的http连接占据着nginx的连接数。
总之：
keepalive_timeout参数，对于提供静态内容的网站来说，这个功能通常是很有用的；
但是对于负担较重的网站来说，存在一个问题：虽然为客户保留打开的连接有一定的好处，但它同样影响了性能，因为在处理暂停期间，本来可以释放的资源仍旧被占用。当Web服务器和应用服务器在同一台机器上运行时，该功能对资源利用的影响尤其突出。
优点是:在请求大量小文件的时候,长连接的有效使用可以减少重建连接的开销.
缺点是:当长连接时间过长,比如60s,即使是浏览器没有任何请求,服务器仍然会维护着该浏览器的连接,一旦用户很多,对apache而言,就是需要维护大量的空闲进程.而对使用线程的轻量级web服务器如nginx,会由于超时时间过长而使资源无效占有而引发的损失,已超过了由于重复连接而造成的损失..
=======================================================================================
另外补充下php配置里对上传大小的限制：
打开php.ini 文件中，主要修改以下几个参数
;This sets the maximum amount of memory in bytes that a script is allowed to allocate
memory_limit = 32M
;The maximum size of an uploaded file.
upload_max_filesize = 8M
;Sets max size of post data allowed. This setting also affects file upload. To upload large files, this value must be larger than upload_max_filesize
post_max_size = 16M
keepalive_timeout这个是nginx里关于http连接超时的一个设置，功能是使客户端到服务器端的连接在设定的时间内持续有效，当出现对服务器的后继请求时，该功能避免了建立或者重新建立连接。切记这个参数也不能设置过大！
因为客户端接口访问其实是一个比较快速的过程，访问完成了就不需要继续使用http连接了，如果将该参数值设置过大，就会导致接口访问完成后http连接并没有被释放掉，所以导致连接数越来越大，最终nginx崩溃！