今天在網上看到一篇不錯的文章。供自己參考。
1.接受壓測任務
真的沒有想到sina的要求還是比較嚴格的，而且是必須通過他們的測試才行
2.理解壓力測試需求
手頭有一份壓力測試的樣例文件，對於“服務器每秒處理能力”的結果如何獲得沒有想法
3.尋找壓力測試軟件
一開始使用siege測試，但是對於當時的apache服務器，無法測試每秒200次併發的情況，就放棄了，不過後來發現，其實不必測試這麼多次的併發，也是可以得到跟sina基本一致的數據。
放棄了siege後，開始使用webbench，不再有200次併發的限制，但是有個問題，返回的結果信息過於簡單，只有成功次數和失敗次數。
當時使用30000的併發，雖然錯誤次數增加了，但是沒有宕機，而且正確次數也在95%以上，所以認爲就算通過了。寫了份報告提交給sina工程師E。
4、sina工程師E的反饋
E的報告徹底擊倒我了，最複雜的初始化人物接口，在30的併發數下，每秒處理能力只有10次左右。我想，會不會是併發數太小的原因，E將併發提升到50，服務器每秒處理能力在15次左右徘徊，E說可以認爲15就是該接口每秒處理次數了，遠遠低於標準了。E用的測試軟件是LoadRunner。
5.LoadRunner
鑑於我當時認爲Loadrunner和webbench測試結果相差太大，所以我也決定用loadrunner。下載了8.0的版本，有300M左右，安裝好後，機子卡不說，居然把我管理員賬號佔用了，系統登錄的時候，是Loadrunner的賬號，還需要密碼。我當時就崩潰了，不至於要重裝系統吧。後來在網上找到了該默認賬號的默認密碼，但進入系統啓動loadrunner後，對裏面如何寫測試腳本，沒有找到門道。放棄了。後來，另外一名技術人員T也嘗試使用Loadrunner，是11的版本，一共有4G，但是有2個模塊安裝不上，而且還是不知道如何使用，目前還是放棄。
順道說下，loadrunner強大的分析能力，生成報表能力，根據場景寫測試腳本，測試流程的功能的確不是其他開源簡單的壓力測試軟件可以相比的。
6.尋找瓶頸
安裝了php的擴展xhprof，可以分析每個頁面的所有函數執行時間，很不錯。
從中檢查出一出重大拖累性能的地方：程序中有一處是解析文件，並且把文件的內容放入數組，耗費了很大的時間，將這部分數據放在NoSql中，效率提升了。
從這裏得到了很大的鼓勵，繼續研究是否還有需要優化的地方。可惜的是，並沒有找到更有價值的優化點。
7.webbench+xhprof分析
單個頁面如何刷新，都能得到比較理想的速度，但是依然通過不了E的指標。
在這樣的情況下，決定使用webbench來做併發，並用xhprof記錄每次的執行效率。
測試後發現，生成的1000份報告中，前15%的處理速度是比較理想和接近的，但是中間部分會有一個突然很大的起伏，耗費的時間一下陡增了10倍左右，分析了報告，瓶頸主要卡在PDO_MYSQL，Nosql的處理上。似乎找到了點瓶頸的落點。
8.第一次解決方案
調整apache的最大連接數等參數，調整mysql的最大連接數，測試了一下，基本沒有太大的變化。再次開會，壓力測試遲遲沒有進展，我的壓力開始增大。
我跟T說，讓總部負責運維的人來幫忙吧。
9.總部運維同事重新部署系統
總部的運維幫我們安裝了nginx，php，mysql。由於總部並沒有使用過Nosql（TT）的經驗，所以php的Nosql（TT）擴展等相關由我們這裏來負責。
部署完畢後測試，基本沒有太多的變化，只好重新開始思考優化方案。
10.NoSql（TT）和 MYSQL 分流
使用了另外一臺服務器，把NOSQL（TT）部署在該臺服務器上，該臺服務器ping當前服務器爲10ms。
結果xhprof的報告更差了，平均比以前慢了10倍，分析代碼，NOSQL（TT）的get，put，有數百次，每次都延時10ms，不慢纔怪。
MYSQL部署在外部的結果沒有太大起色。
11.確認測試數據
根據我一個朋友給的騰訊的壓力測試需求，150併發，每個請求200ms以內，我也打算使用150的併發，然後再查看成功次數。
然後運行初始化接口，每秒最多完成20次的請求，跟sina數據基本一致。
12.新的查找瓶頸方案
空代碼運行，發現每秒完成在1200次以上，但是執行了我們的代碼，效率下降很快，所以認爲代碼優化的潛力很大。
決定從初始化接口開始，一行一行代碼的測試。
13.第一個瓶頸點
增加一個非空的判斷，使得每秒處理次數大幅提升，同時使用單例模式，減少開銷。
提升了20%的效率。
14.第一個加速點
安裝php加速器eaccelerator，速度提升了30%左右。
15.第二個加速點
配置Nosql（tt），使用的方法會在其他的帖子詳細說明，提升了5%-10%的速度。其實tt不做任何的配置，他的默認配置下速度也是很快的。
16.第三個提升點
將TT中過大的數據切割成較小的數據，雖然多了get的次數，但是速度卻很大的提升，30%-40%應該是有的。
至於多大的數據需要切割，我並沒有更詳細的測試，我這次切割的數據高達800k，高併發下速度會下降得很厲害，切割成小塊不超過200k的數據後，速度提升非常明顯。
17.第四個提升點
修改系統內核，增加系統允許的最大訪問次數，最大程度發揮TT的效率，這裏可以貼出E的參考方案，在50000次併發以上效果明顯。
- #!/bin/sh
- sysctl -w net.ipv4.tcp_tw_reuse=1
- sysctl -w net.ipv4.tcp_tw_recycle=1
- sysctl -w net.ipv4.tcp_fin_timeout=10
- sysctl -w net.core.wmem_max=8388608
- sysctl -w net.core.rmem_max=8388608
18.第五個提升點
sina工程師E報告還說，會偶爾出現pdo_mysql連接不上的錯誤。
於是用程序做了一個分流，把user_id爲奇數的數據庫查詢放到了另外一臺服務器上，解決了這個問題。
轉載來自：http://crizy.iteye.com/blog/1171410