Java NIO框架Netty教程(十三)
阿新 • • 發佈:2018-12-23
在上節(《Java NIO框架Netty教程(十二)-併發訪問測試(中)》),我們從各個角度對Netty併發的場景進行了測試。這節,我們將重點關注上節最後提到的問題。在多執行緒併發訪問的情況下,會出現
警告: EXCEPTION, please implement one.coder.netty.chapter.eight.ObjectClientHandler.exceptionCaught() for proper handling. java.net.ConnectException: Connection refused: no further information的錯誤警告。 之前
a) windows -- 1、開啟登錄檔:regedit 2、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters 3、新建 DWORD值,name:TcpTimedWaitDelay,value:0(十進位制) –> 設定為0 4、新建 DWORD值,name:MaxUserPort,value:65534(十進位制) –> 設定最大連線數65534 5、重啟系統 b) linux -- 1、檢視有關的選項 /sbin/sysctl -a|grep net.ipv4.tcp_tw net.ipv4.tcp_tw_reuse = 0 #表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連線,預設為0,表示關閉; net.ipv4.tcp_tw_recycle = 0 #表示開啟TCP連線中TIME-WAIT sockets的快速回收,預設為0,表示關閉 2、修改 vi /etc/sysctl.conf net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 3、使核心引數生效sysctl -p
這套配置在測試Restlet框架併發的時候,起到了明顯的效果。
然後,這次即使 OneCoder 修改配置,併發連線也沒有明顯的上升。 OneCoder 決定換個思路,啟動多個程序對同一個服務進行持續訪問,以證明之前的連線拒絕就是因為客戶端多執行緒併發自身的問題(其實 OneCoder 一直非常懷疑是這個問題)還是服務端連線處理的問題。 修改了一下客戶端發動訊息的程式碼,使其在其執行緒內部,不停的給服務端傳送資訊。 **
* 傳送Object
*
* @param channel
* @author lihzh
* @alia OneCoder
* @blog http://www.coderli.com
*/
private void sendObject(final Channel channel) {
new Thread(new Runnable() {
@Override
public void run() {
// TODO Auto-generated method stub
for (;;) {
Command command = new Command();
command.setActionName("Hello action.");
channel.write(command);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}).start();
}
啟動多個客戶端,效果如圖:
果然,在單個程序數量控制合理的情況下,服務端可以處理所有請求,不會出現連結拒絕的情況。總連線數輕鬆達到4,5k。( OneCoder 注:以前超過1000都容易出錯。這裡只是測試到以前完全沒有辦法支援的情形,並沒有測試最大壓力值。) 對於測試Netty服務端壓力來說,這樣的測試, OneCoder 認為完全可以起到效果,有參考價值。因為即使單程序網路連線方面無上限,單程序能啟動的執行緒數也是有限制的,效率也一定會受到影響。所以,對於併發測試來說, OneCoder 認為可以採用上面的方式。 對於,單程序多執行緒的時,拒絕連線的問題。是在sun.nio.ch.SocketChannelImple 中的native方法checkConnect中丟擲的。這應該是跟作業系統密切相關的。 OneCoder 沒有在linux下進行測試,但是猜測在linux下,上面的設定引數是可以起到作用的,也就是會比windows下可以開啟的併發執行緒數多。當然這只是猜測。 對於windows來說,揪淨能開啟多個執行緒的併發,這個資料在 OneCoder 的環境下也是非常不穩定的。最開始的時候是,起1000個執行緒,成功的350個執行緒左右。後來, OneCoder 懷疑啟動的程式過多,尤其是跟網路相關的程式會影響測試結果,關閉了很多程式。結果,多次1000執行緒都成功連線。 OneCoder仔細排查了一下,猛然發現 OneCoder 使用了Proxifier這個代理。在代理開啟的情況下,一般只能跑到300左右。關閉有1000個執行緒基本穩定通過。最多可以跑到1500左右。目前被列為最大“嫌疑人” 以 OneCoder 目前的知識構成來說,Netty併發的測試基本可以告一段落了。再簡單的總結嘮到幾句:- 如果需要測試併發,可以考慮多程序,程序內多執行緒的方式測試服務端壓力。
- OneCoder 沒有測試Netty最大可以支援多少併發,因為從目前測試的效果來看。(5個程序,每個程序1000執行緒,持續訪問同一個服務),已經完全可以滿足 OneCoder 的要求了。您也可以繼續測試下去。
- OneCoder 使用的是windows7 32位作業系統,在測試過程其實也修改了登錄檔中的若干引數,包括上面提到的兩個。不知道是否起到了一定的作用,也就是是否使單程序可以支援的多執行緒數增加,或者服務端可以支援的連線數增加,您在測試的過程中,可以配合考慮這些引數。
- 對於,connection refuse的具體原因, OneCoder 希望能隨著自己知識的慢慢積累,找到其真正的答案。