現在關鍵詞排名優化的時候，經常被高手請疏忽，針對一些初入技巧職場的童鞋，欲望能對各位碰到后果時分的思考方法有所協助。

案例1：詭異的鏈接過量

    事先狀況是如許，突然有一天，數據庫出現鏈接過量毛病，招致網站報錯。 熟悉mysql并操作太高并發系統的冤家知道，數據連接過量屬于很罕見的后果。但事先的狀況是，訪問量其實不在高峰，按理說不應當有如許的后果。

    看了一下數據庫效勞器的負載，很低，其實不存在cpu或內存跑滿的后果。

    慢查詢日記沒有異常的SQL，更沒有鎖表。

    因而就進入數據庫做一下 show processlist的查詢。

    有些冤家能夠會問，鏈接過量你還能看show processlist么，阿誰，mysql里root比通俗用戶多一個鏈接容許，所以，記得依次切忌用root鏈接，保管一個給系統剖析師用。

    意外發明，簡直一切的SQL逗留在sleep形狀，而且很多鏈接都繼續了好幾秒，乃至十幾秒。

    這里說明一下，假設是用數據中間件鏈接池來操作，從中間件到數據庫存在固定命字的sleep鏈接是正常的，但從依次端到中間件，除非你是長連接，而且需求保持數據庫頻繁操作的應用，否則，平日不建議數據庫保持連接，也就是不應當出現太多sleep操作。

    我們的場景就是通俗的web應用，php依次而已，都是短鏈接，按理說，依次履行完就應當釋放的，所以這個后果就有點意外。

    固然，這個和代碼的設計也有關系，因為系統用的開源軟件改寫的，觸及數據庫操作照樣蠻多的，通俗狀況下，數據庫操作完應當及時封閉，但因為通俗認為php代碼履行時間很短，所以在代碼架構有點復雜的狀況下，很多都是默許全部依次履行完再封閉。那么現在后果來了，究竟php爆發了甚么后果。

    我們去web效勞器，看日記，發明訪問量并沒有異常，也沒有針對我們的進擊行動，但確實很多php依次履行時間較長，web連接數也清晰多于異常，即使是數據庫重啟，后果依然會重現，那么這時候分，我們工程師就在最經常使用的php代碼里設置斷點，去看代碼究竟卡在哪個環節上履行時間很長，結果，發明是我們的一個十分主要的常識盲點。本來履行時間最長的，是在最后代碼數據都履行完，輸入履行 echo  的環節。

    在當地做功用測試，壓力測試的時分，我們知道echo 這類語句是基本沒有開支的，也不太能夠成為一種負載的起源，但這下我們明確了，echo本來不只僅是php履行輸入，也包羅了收集傳輸的時間開支。只要客戶端回收到傳輸內容后，echo履行才完畢。

    而那天的后果，實際上是因為同機房有其他公司效勞器被Ddos，招致機房出口擁堵，按理說這只是websever的后果，但因為webserver自身有輪詢機制，而且設置的連接數較大年夜，固然訪問較慢，但沒有解體，而因為php代碼里mysql鏈接沒有及時釋放，在php履行echo的時間等待較長，招致mysql鏈接過量解體。

    知道這個后果，處理就復雜了，因為開源系統封裝了輸入template的對象，我們就在這個對象履行的時分，先履行mysql_close(); 如許只改了一行代碼，后果就處理了。

    但后來發明出了bug，bug的來由很無厘頭，居然局部template 的偽碼里有數據庫操作，但這個后果處理也復雜，因為究竟如許的場景很少， 而且mysql對象也被封裝了，我們就在query方法里加了一行代碼，假設沒有數據庫連接，就重建一個。 如許，這個重建過程只出現在極少數template里有mysql操作的場景，對全部系統基本沒有功無能擾。

    這個案例說來挺復雜，就是數據庫連接沒有及時釋放形成的，但因為震動了一個思維盲區，所以印象深入。

    線上的依次做斷點日記剖析是最經常使用的剖析詭異后果的方法。基于斷點日記剖析，我們可以經過相似二分法，逐漸遞進直到準肯定位具體到每行代碼的履行時間開支。

    這里還要提醒一個罕見后果，線上情況很多后果是在測試情況里很難重現的，所以碰到詭異后果，應當可以在線上做一些日記剖析和代碼的調試，固然如許能夠會有必然的風險，但很多公司的流程和規范，開辟工程師只能在線下測試功用和壓力接受才華，針對線上很多抱負的后果沒有方法完整實測。

    大年夜公司能夠會把測試情況做的更好更規范，和有更有經歷的工程師和剖析師來處理后果，但創業公司，我建議要給依次員和剖析人員一些線上應急處理的權限，否則真的會束手無策，經歷值都是靠出錯和處理后果來積累的。