網站速度定位
總體思想：
1、找瓶頸法。瓶子的頸部(口子)大小決定了出入量，從而決定了速度。不去改善瓶頸，使勁費力氣把瓶子容量擴大，
速度也不會提高。不是什麼都去改善就是好的。比如改善頻寬，加快取之類的。但是這些不是目前系統的瓶頸，改善
了也不會發生質的飛躍。所以找到瓶頸所在。
與哲學思想中的：找主要矛盾，解決主要矛盾，問題才會解決的思想類似。放到技術中叫做系統瓶頸。突破系統瓶頸。
找到當前的主要矛盾是重要的。去研究程式碼，獲取幾毫秒的效能，不如去看看資料庫，幹掉一條執行超過1000毫秒的語句。
遇到速度慢的問題，就想到“多多益善”的思維。把該加的先加了：把資料生成檔案快取啊,資料庫加索引，硬體方面記憶體加，頻寬加。
這種加，確實有好處，會改善，但沒定位到瓶頸。就不會解決主要矛盾的。
系統的某方面瓶頸沒有突破，其他頻寬，記憶體再怎麼加，做了觀察一段時間後，就發現心裡很納悶了：確實是快那麼點點了，但怎麼還是沒感覺到明顯的快哦。有時候反而跟以前一樣的慢。很鬱悶啊。
2、使用排除法查詢問題。這樣將範圍逐步縮小。避免胡亂猜測。胡亂去測驗。導致浪費精力。
大體思路：前端(排查是不是頻寬問題,圖片、js檔案載入是否是瓶頸)》》偵測php執行速度(這一步把問題可以更加精準定位到資料庫層面去)》》資料庫是否為瓶頸
3、以資料或者理論作為支撐。如果靠猜測，以往經驗式的判斷方式去改善，只會導致做無用功。以統計資料作為支撐比較靠譜。
因為網站執行是動態的，時常速度很快，時常速度稍微慢。今天有人反應昨天慢，等到技術人員去實際操作一下子，發現"速度還挺不錯啊"，無法還原當時的情況出來。
比如，sql執行時長，php指令碼執行速度統計。收集大量在生成環境中統計到的資料。就能很快定位問題所在。
依靠理論作為支撐：比如瞭解http的請求原理，需要響應，瀏覽器沒有得到伺服器的響應(也就是php壓根就沒執行完畢，所以沒到傳送html給瀏覽器這一步)，這種情況在瀏覽器左下角有明顯的特點，顯示：正在等待響應。
這種一看，大體可以排除網路頻寬的原因。這種判斷表面看是基於經驗式(經驗不可靠，因為網站是動態變化的)，實際上是基於有理論基礎支援的。
執行步驟如下：
第一步，編寫指令碼統計出php執行時長。通過這一步把每次執行時長記錄在文字檔案中的方式，分析資料發現，排除了
是頻寬的原因。理由為：有些地址的php執行時長到3-4s。需要這個時長才能發html結果給瀏覽器。可想而知速度。於
是瓶頸不在頻寬上。假設：php執行的時長是0.xs級別。那麼在瀏覽器看到需要4秒才能看到頁面，那可以排除是php執
行問題。將瓶頸定位在頻寬或其他原因上。
第二步，進一步編寫指令碼，偵測是否為資料庫速度問題。
具體步驟如下
1、開啟mysql伺服器的慢查詢日誌記錄。
2、自己編寫指令碼，將每條執行的sql用了多長時間，記錄到文字檔案中去。