nginx讀取超時問題案例分析

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

問題描述

我們這個業務輸出形式類似芝麻評分，部署架構是 接入層-》業務邏輯-》評分服務層。每個層對應一個物理進程。真正計算分數的就是評分服務層。我想按照這樣的步驟依次查詢問題：1 評分服務是否達到性能上線 2 是否業務邏輯層訪問評分服務條件苛刻

1 評分服務是否達到性能上線

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

• 平均響耗時時間 301ms

• 標準查 238ms

• 最小耗時時間 6ms

• 前25%耗時時間 176ms

• 前75%耗時時間 372ms

• 前90%耗時時間 511ms

• 前99%耗時時間 993ms

• 最大耗時時間 15000ms

• 高于10秒的數量 26筆

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

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

2 是否業務邏輯層訪問評分服務條件苛刻

業務邏輯訪問評分服務是通過nginx做反向代理的，最終請求是負載到多個服務器上。我們觀察當時的nginx訪問日志，發現有499的情況。

nginx 499 CLIENT CLOSED REQUEST

nginx引入的非標準的狀態碼，來表示當nginx正在處理請求時，客戶端關閉了連接

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

方案

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

方案2，在評分服務層解決，找出消耗時間比較大的代碼位置，考慮優化。缺點，周期比較長

方案3，橫向拓展評分服務層。缺點，消耗機器資源（沒那多的錢買機器）

潛在的問題

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

我們統計了評分服務耗時時間相關指標，百分之99的交易均能在993ms，即1s內完成，真正耗時長的交易非常少，所以對整體的系統吞吐量基本構不成影響。

到此，關于“nginx讀取超時問題案例分析”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！