http_load：以並行復用的方式執行，用以測試
webx
伺服器的吞吐量與負載。但是它不同於大多數壓力測試工具，它可以以乙個單一的程序執行，一般不會把客戶機高斯，還可以測試
類的**請求。
http_load用法：
注：常用方式：
模擬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
請求，不一樣的結果的個數。
說明開啟響應頁面的型別，如果
403的型別過多，那可能要注意是否系統遇到了瓶頸。
code 200 – 10772495
這裡主要看的引數有
fetches/sec
，msecs/first-response
。要統計
timeout
的比例：
timeouts/
fetches
。這裡的超時比例就是：
23088/10799998=0.213%
。同時還要伺服器端的
cpu，
mem和
load
。通常load
數/cpu
個數<=1
是比較好的。
關於超時：
預設的超時時間為
10s，這裡的超時可以自己定義，但必須是
int整數，不能是浮點數。
關於每秒種的請求數
-r，如果
pd有給期望的pv或
uv，那麼可大概算出
qps，一般
qps=pv/（60
×60×6
）一般，每天按照
6個小時算。如果沒有期望值和參考值，那麼就要去乙個個試，看
r為多少時，系統的效能達到最大值，要試出乙個臨界值。注：r
就代表qps
，即結果中的引數
fetches/sec
值。如果
r太大時，系統可能會壓掛或者不穩定，此時
qps跟
r的差別較大，壓測結果不具備參考性，要適當降低r值。
第一次效能測試 http load
http load 以並行復用的方式執行，用以測試webx伺服器的吞吐量與負載。但是它不同於大多數壓力測試工具，它可以以乙個單一的程序執行，一般不會把客戶機高斯，還可以測試https類的 請求。http load用法 注 常用方式 http load r 200 s 900 http.txt 2 2...
第一次測試總結
對於本次測試，自己感到很不理想，原以為之前已經做過很多次這套題了，從線上最後一次課結束到現在便沒有進行複習，認為自己僅有的基礎已經 勝券在握 但事實卻狠狠地打了自己的臉，導致幾個失分點並非不會而是記憶模糊從而沒能實現功能。通過本次測試，我進一步發現了自己的不足點，如下 1 ajax刪除掌握的不夠牢固...
記錄一次效能優化
做了這麼久開發，終於涉及到效能優化了 原因是開啟乙個頁面花了2 6秒，被提了bug 不得不說自己有點小白，嘗試了非同步執行緒和把單次的dubbo查詢優化成批量的查詢。但是這兩種嘗試都沒有宣告成功 出了問題首先要找到問題在 既然是耗時，那就要看看到底 耗時最多 這裡要說一下，因為我是改別人的 所以對業...