最近專案中遇到了一次curl超時，導致了使用者操作寫入失敗的問題
1、curl超時怎樣去追蹤哪乙個步驟導致超時
php 超時原理：
一次請求呼叫某個api出現超時的時候我們如何判定是在哪乙個步驟超時了？
1、網路原因，請求超時，服務端**未執行，很容易判斷，超時後，服務端無任何操作
2、服務端執行超時，服務端**已執行，但並未執行完已經超出設定的超時時間
針對第二種情況，要首先分析出服務端**已經執行到哪乙個步驟了，接著看一下將要執行卻未執行的步驟是什麼，分析出是不是該步驟導致超時，是則針對該步驟進行優化，不是則向前分析，判斷出之前執行過的哪個步驟比較耗時，導致後邊超時。
2、一次操作多次呼叫某個非同步服務的處理方式
當我們在一次操作中需要去多次呼叫乙個tcp非同步服務（有連線超時時間）的時候，如何盡可能地減少服務掛了對我們造成的影響
我的理解是將這多次呼叫封裝到乙個api介面中，然後去非同步呼叫一次，這樣即使非同步服務掛了，也只會連線超時一次。
3、乙個服務我們主觀判定不好用之後第一反應難道應該是棄用？
最起碼我不這麼認為，我更傾向於去找出來是它真的不好用還是自己沒有用好。
4、作為乙個研發，我從來沒想過推卸責任
當在乙個團隊中，出現了一些問題，解決方案都還沒出來，卻有人已經開始想著推卸責任的時候，那一刻
，我真的很想離開這個團隊。但或許我們更應該想的是如果我是團隊管理人員，如何解決這種問題？
關於線上一次超時處理引發的思考
關於線上一次超時處理引發的思考 背景最近關於線上關於註冊問題有超時2s的情況發生，最長時間已經是9s多，上游系統最多只能等待2s就返回超時失敗。影響造成線上上游系統出現註冊失敗，影響非常不好。告警郵件和簡訊頻發。問題排查鏈路 解決方案 各系統檢查自己對應介面耗時情況，運維負責檢查osg nginx問...
記一次mysql鎖超時問題
排查過程 select from information schema.innodb lock waits select from information schema.innodb trx show engine innodb status show variables like autocomm...
一次線上服務呼叫超時優化問題
原文 最近線上環境有個檔案列表超時無響應 去資料庫模擬查詢後發現需要打約1200ms左右的時間，但是線上的服務呼叫超時時間設定的1000ms 改動之前邏輯是在乙個for迴圈中會訪問三次資料庫，造成比較多的訪問資料庫開銷 for d d list centity c cdao.getbyid bid ...