nginx讀取超時問題案例分析

這篇文章主要介紹“nginx讀取超時問題案例分析”，在日常操作中，相信很多人在nginx讀取超時問題案例分析問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”nginx讀取超時問題案例分析”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

問題描述

我們這個業(yè)務(wù)輸出形式類似芝麻評分，部署架構(gòu)是 接入層-》業(yè)務(wù)邏輯-》評分服務(wù)層。每個層對應(yīng)一個物理進(jìn)程。真正計算分?jǐn)?shù)的就是評分服務(wù)層。我想按照這樣的步驟依次查詢問題：1 評分服務(wù)是否達(dá)到性能上線 2 是否業(yè)務(wù)邏輯層訪問評分服務(wù)條件苛刻

1 評分服務(wù)是否達(dá)到性能上線

我對評分服務(wù)的交易時間做了一個統(tǒng)計，樣本量95w：

• 平均響耗時時間 301ms

• 標(biāo)準(zhǔn)查 238ms

• 最小耗時時間 6ms

• 前25%耗時時間 176ms

• 前75%耗時時間 372ms

• 前90%耗時時間 511ms

• 前99%耗時時間 993ms

• 最大耗時時間 15000ms

• 高于10秒的數(shù)量 26筆

沒有處理失敗的交易，但是有耗時比較長的交易，評分服務(wù)并沒有達(dá)到上限。

為什么有的交易耗時超過10s？從業(yè)務(wù)的角度說，可能某個人的數(shù)據(jù)量大，計算占用io和cpu都比較大。

2 是否業(yè)務(wù)邏輯層訪問評分服務(wù)條件苛刻

業(yè)務(wù)邏輯訪問評分服務(wù)是通過nginx做反向代理的，最終請求是負(fù)載到多個服務(wù)器上。我們觀察當(dāng)時的nginx訪問日志，發(fā)現(xiàn)有499的情況。

nginx 499 CLIENT CLOSED REQUEST

nginx引入的非標(biāo)準(zhǔn)的狀態(tài)碼，來表示當(dāng)nginx正在處理請求時，客戶端關(guān)閉了連接

我查詢了業(yè)務(wù)邏輯層訪問評分服務(wù)的時間：連接2秒，讀取10秒。問題找到，當(dāng)評分服務(wù)負(fù)載比較大時，處理某些請求的時間可能會超過10秒。因為業(yè)務(wù)邏輯層設(shè)置的讀取超時時間10s，所以主動斷開了連接。

方案

方案1，修改業(yè)務(wù)邏輯層訪問評分服務(wù)和接入層訪問業(yè)務(wù)邏輯層的讀取時間，大于評分服務(wù)正常處理請求的最大時間。缺點(diǎn)：這是治標(biāo)不治本的方法，客戶的體驗比較差。

方案2，在評分服務(wù)層解決，找出消耗時間比較大的代碼位置，考慮優(yōu)化。缺點(diǎn)，周期比較長

方案3，橫向拓展評分服務(wù)層。缺點(diǎn)，消耗機(jī)器資源（沒那多的錢買機(jī)器）

潛在的問題

增大客戶端的讀取時間，是否會影響整體系統(tǒng)的吞吐量

我們統(tǒng)計了評分服務(wù)耗時時間相關(guān)指標(biāo)，百分之99的交易均能在993ms，即1s內(nèi)完成，真正耗時長的交易非常少，所以對整體的系統(tǒng)吞吐量基本構(gòu)不成影響。

到此，關(guān)于“nginx讀取超時問題案例分析”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！