http_load：以並行復用的方式執行，用以測試webx伺服器的吞吐量與負載。但是它不同於大多數壓力測試工具，它可以以乙個單一的程序執行，一般不會把客戶機高斯，還可以測試https類的**請求。
http_load用法：
注：常用方式：./http_load –r 200 –s 900 http.txt 2>2.log 1>1.txt
模擬qps200，連續壓測15分鐘，錯誤日誌輸出到2.log檔案中，最終的壓測結果輸出到1.txt檔案中。
結果分析：
1. 10799998 fetches, 1020 max parallel, 3.17224e+10 bytes, in 43200 seconds//說明測試中執行了10799998個請求，最大的併發程序數是1020，總計傳輸的資料是3.17224e+10 bytes，執行的時間是432000秒
2. 2937.26 mean bytes/connection//說明每一連線平均傳輸的資料量是（3.17224e+10）/10799998=2937.26
3. 250 fetches/sec, 734315 bytes/sec//說明每秒的響應請求為250，每秒傳遞的資料為734315 bytes
4. msecs/connect: 0.194116 mean, 30.207 max, 0.125 min//說明每鏈結的平均響應時間是0.194116 msecs，最大的響應時間是30.207msecs，最小的響應時間是0.125 msecs
5. msecs/first-response: 22.9355 mean, 59996.9 max, 0.07 min//說明每個請求的平均響應時間是22.9355msecs，最大的響應時間是30.207msecs，最小的響應時間是0.07msecs。
6. 23088 timeouts//執行中有23088個請求超時
7. 27503 bad byte counts//同乙個http請求，不一樣的結果的個數。
8. http response codes://說明開啟響應頁面的型別，如果403的型別過多，那可能要注意是否系統遇到了瓶頸。
code 200 – 10772495
這裡主要看的引數有fetches/sec，msecs/first-response。要統計timeout的比例：timeouts/ fetches。這裡的超時比例就是：23088/10799998=0.213%。
同時還要伺服器端的cpu，mem和load。通常load數/cpu個數<=1是比較好的。
關於超時：http_load預設的超時時間為10s，這裡的超時可以自己定義，但必須是int整數，不能是浮點數。
關於每秒種的請求數-r，如果pd有給期望的pv或uv，那麼可大概算出qps，一般
qps=pv/（60×60×6）一般，每天按照6個小時算。如果沒有期望值和參考值，那麼就要去乙個個試，看r為多少時，系統的效能達到最大值，要試出乙個臨界值。
第一次效能測試 http load
http load 以並行復用的方式執行，用以測試 webx 伺服器的吞吐量與負載。但是它不同於大多數壓力測試工具，它可以以乙個單一的程序執行，一般不會把客戶機高斯，還可以測試 類的 請求。http load用法 注 常用方式 模擬qps200 連續壓測 15分鐘，錯誤日誌輸出到 2.log 檔案中...
第一次測試總結
對於本次測試，自己感到很不理想，原以為之前已經做過很多次這套題了，從線上最後一次課結束到現在便沒有進行複習，認為自己僅有的基礎已經 勝券在握 但事實卻狠狠地打了自己的臉，導致幾個失分點並非不會而是記憶模糊從而沒能實現功能。通過本次測試，我進一步發現了自己的不足點，如下 1 ajax刪除掌握的不夠牢固...
記錄一次效能優化
做了這麼久開發，終於涉及到效能優化了 原因是開啟乙個頁面花了2 6秒，被提了bug 不得不說自己有點小白，嘗試了非同步執行緒和把單次的dubbo查詢優化成批量的查詢。但是這兩種嘗試都沒有宣告成功 出了問題首先要找到問題在 既然是耗時，那就要看看到底 耗時最多 這裡要說一下，因為我是改別人的 所以對業...