nginx與客戶端預設是長連線，nginx與uwsgi的長連線需要設定keepalive和Http1.1，uwsgi與nginx的長連線需要設定http11-socket。

在設定了nginx upstream keepalive 為100的情況下。測試發現，長連線狀態下，uwsgi程序沒有充分忙碌，在壓測的情形下，新使用者請求到來，這個新請求會得到快速處理；短連線情況下，客戶端得到的響應時間是平滑的，在壓測的情形下，使用者的新請求到來時，響應時間會稍慢，與壓測的平均響應時間一致。

在我的例子中，長連線的耗時比短連線的耗時多。

1. nginx

1.1 客戶端與nginx的長連線

1. keepalive_timeout:客戶端與nginx之間的長連線超時設定，當一個連線的最後一次資料傳輸至今超過了這個時間，那麼當前連線就會被服務端主動關閉。 預設值60s，因此客戶端與Nginx預設是長連線的。
2. 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 "";
        }
    }

1. 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地址查詢匹配，這樣方能攜帶前端標識，避免多個前端共用一個後端連線從而影響效能的問題。
2. proxy_connect_timeout：與後端伺服器建立連線的超時時間，我目前的理解是建立開始至建立連線成功的時間，Nginx官方提示這個超時一般不要大於75秒。
3. proxy_send_timeout：預設60s，定義向後端伺服器傳輸請求的超時。這是向server傳送相鄰的兩個請求之間的最長時間間隔。如果後端伺服器在超時時間段內沒有接收到任何資料，連線將被關閉。
4. proxy_read_timeout：預設60s,定義從後端伺服器讀取響應的超時。此超時是指相鄰兩次讀操作之間的最長時間間隔，而不是整個響應傳輸完成的最長時間。如果後端伺服器在超時時間段內沒有返回任何資料，連線將被關閉。如果後端處理請求的耗時較久，需要把這個設定項設定得大一些。

2. uwsgi

1. http11-socket：使用HTTP 1.1 (Keep-Alive)協議繫結到指定UNIX/TCP socket上
2. processes： 一般設定為cpu核數的兩倍，不是越大越好。我曾經以為設定大了，併發效能會更好，將該值設定為80，5000個請求在300併發的情況下最後三個左右的響應總是超時，降低該值後不再出現超時。

參考文獻

1. 【nginx優化——包括https、keepalive等】
2. 【Nginx Upstream Keepalive 分析】