SS5壓力測試
網絡監控方法
dstat命令，所代表的receive/send，貌似receive是接收的字節數，*8是帶寬，而send並不是機器對外網發送的字節數，故不用它判斷收發流量；
iftop命令，在實驗場景下（每秒大約4個baidu首頁請求，接收流量大約138KB*4），顯示的發送和接收的流量，和程序計算的每秒發送接收流量基本一致，故採用這個命令，判斷網絡流量。
SS5日誌
1、STARTED和TERMINATED是配對出現的，代表一次連接的開始和結束
[08/Apr/2015:19:46:57 CST] [1035835136] 10.10.96.106 "" "CONNECT" STARTED 0 0 0 (10.10.96.106:55389 -> 220.181.112.244:80)
[08/Apr/2015:19:48:03 CST] [1035835136] 10.10.96.106 "" "CONNECT" TERMINATED 23189 352 66 (10.10.96.106:55389 -> 220.181.112.244:80)
2、不是每一次代理請求都會被記錄下來
當我們訪問公網時，由於一次Socket請求（Client：IP+Port和Server：IP+Port）會延續較長時間，所以基本不會在1秒內被複用，所以基本都能記錄日誌；
當我們測試訪問一個內網URL時，1秒內完成幾百次成功的Socket請求，很多被複用，對於1秒內“Client：IP+Port和Server：IP+Port”相同的Socket，SS5認爲是一個，只有1行日誌；
這樣，可以解釋，訪問內網URL時，幾千個成功的請求，只有幾百行日誌的場景。
以上兩種日誌場景，我們都認爲是正常的。
3、Socks method unknown or bad request
telnet 1080端口，輸入字符；或者F5心跳檢測1080端口，都會導致這個日誌不斷報出。這個應該通過更好的配置過濾掉。
性能指標
大併發情況下，Socket連接沒有正常及時釋放，或者到達臨界值，如下錯誤報出。
日誌會報如下錯誤（刷屏）：
[08/Apr/2015:16:06:23 CST] [0] [ERRO] $S5ServerAccept$: (Too many open files).
[08/Apr/2015:16:06:23 CST] [1916823296] [ERRO] $S5GetClientInfo$: (Bad file descriptor).
程序會報如下錯誤：
java.net.SocketException: SOCKS server general failure
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:526)
at java.net.Socket.connect(Socket.java:529)
at sun.net.NetworkClient.doConnect(NetworkClient.java:158)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:411)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:525)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:208)
at sun.net.www.http.HttpClient.New(HttpClient.java:291)
at sun.net.www.http.HttpClient.New(HttpClient.java:310)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:987)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:966)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841)
at cl.an.HttpConn.run(HttpSocketPressTest.java:188)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
性能測試結果：
| Socket連接數-正常臨界值（約值） | Socket連接數-異常臨界值（約值） | 到達異常臨界值後 | |
| openfiles -1024 | 450 | 550 | 報上面的Bug，只保留200個線程，35秒後恢復正常 |
| openfiles -4096 | 2000 | 2100-2500 | 第一種情況： ss5異常停止，不能恢復：service ss5 status，可以看到： ss5 已死，但是 subsys 被鎖；有時還會報：*** glibc detected *** /usr/sbin/ss5: free(): invalid pointer: 0x00007f693c0207e0 *** 第二種情況： 報上面的Too many open files，只保留200個線程，10秒後恢復； |
| openfiles -65536 | 結果和openfiles -4096類似 |
根據我們的測試結果，可以認爲虛擬機10.100.140.85（4個CPU、6G內存），最大支持2000併發。
官網的性能指標是：IBM X360，支持2500併發數。
查看Socket連接數命令：netstat -napo | grep 1080 | wc -l
查看修改最大同時打開文件數命令：vim /etc/security/limits.conf ，需要新開一個終端，ulimit -n，確認生效了，service ss5 restart，纔會在ss5中生生效。
關於這個值，很多公司這樣設置：
[plain] view plain copy
* soft nofile 1000000
* hard nofile 1000000
* soft core 1048576
* hard core 1048576
參考網址：
http://www.codesky.net/article/201105/161796.html
http://www.justwinit.cn/post/6482/
http://blog.csdn.net/leili0806/article/details/7534985
壓測結果
訪問www.baidu.com（頁面大小：135KB）
1、囿於帶寬限制（實測、搶公網帶寬，只能搶到1.5M-2M左右），所以，平均每秒，只可能有10-20個成功的Http請求返回。
2、會報java.net.SocketTimeoutException: Read timed out：這是因爲網絡帶寬原因，Timeout時間內沒有從流中讀取完成數據所致的。這是正常的，網絡原因，用不用Socket5代理都有這個問題。
3、會報java.net.ConnectException: Connection timed out: connect：也是網絡原因，Timeout時間內，沒有連接遠程服務器成功。這是正常的，網絡原因，用不用Socket5代理都有這個問題。
4、會報java.net.SocketException: Connection reset：懷疑是遠程服務器的原因。
5、測試截圖如下：
iftop：
dstat：
6、測試過程中，watch -n1 -d 'netstat -an | grep 1080'，完全正常，SS5服務本身沒有任何壓力。
7、測試結果：
a、3個機器各開100個併發，成功率分別是：85%、65%、67%，失敗的原因基本是Read timee out，即30秒不能完全從網絡輸入流中讀取完成所有返回數據。
b、1個機器100個併發，成功率大約是98%。
訪問內容URL
可以跑帶寬大約50-60M，平均每秒250個成功返回，成功率100%，截圖如下：
iftop：
dstat：
結論
SS5服務本身能承受巨大壓力，調優ulimit -n後，大約支撐2000併發。
SS5服務，帶寬足夠，請求的文件越小，網絡越好，就能支持更多的成功返回。