您好,登錄后才能下訂單哦!
這篇文章主要介紹“nginx讀取超時問題案例分析”,在日常操作中,相信很多人在nginx讀取超時問題案例分析問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”nginx讀取超時問題案例分析”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
我們這個業務輸出形式類似芝麻評分,部署架構是 接入層-》業務邏輯-》評分服務層。每個層對應一個物理進程。真正計算分數的就是評分服務層。我想按照這樣的步驟依次查詢問題:1 評分服務是否達到性能上線 2 是否業務邏輯層訪問評分服務條件苛刻
我對評分服務的交易時間做了一個統計,樣本量95w:
平均響耗時時間 301ms
標準查 238ms
最小耗時時間 6ms
前25%耗時時間 176ms
前75%耗時時間 372ms
前90%耗時時間 511ms
前99%耗時時間 993ms
最大耗時時間 15000ms
高于10秒的數量 26筆
沒有處理失敗的交易,但是有耗時比較長的交易,評分服務并沒有達到上限。
為什么有的交易耗時超過10s?從業務的角度說,可能某個人的數據量大,計算占用io和cpu都比較大。
業務邏輯訪問評分服務是通過nginx做反向代理的,最終請求是負載到多個服務器上。我們觀察當時的nginx訪問日志,發現有499的情況。
nginx引入的非標準的狀態碼,來表示當nginx正在處理請求時,客戶端關閉了連接
我查詢了業務邏輯層訪問評分服務的時間:連接2秒,讀取10秒。問題找到,當評分服務負載比較大時,處理某些請求的時間可能會超過10秒。因為業務邏輯層設置的讀取超時時間10s,所以主動斷開了連接。
方案1,修改業務邏輯層訪問評分服務和接入層訪問業務邏輯層的讀取時間,大于評分服務正常處理請求的最大時間。缺點:這是治標不治本的方法,客戶的體驗比較差。
方案2,在評分服務層解決,找出消耗時間比較大的代碼位置,考慮優化。缺點,周期比較長
方案3,橫向拓展評分服務層。缺點,消耗機器資源(沒那多的錢買機器)
我們統計了評分服務耗時時間相關指標,百分之99的交易均能在993ms,即1s內完成,真正耗時長的交易非常少,所以對整體的系統吞吐量基本構不成影響。
到此,關于“nginx讀取超時問題案例分析”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。