基於netty的壓力工具和連接計數

我正在爲web應用程序構建一個簡單且最快的壓力測試工具。要求：來自單個節點的外向HTTP請求（例如，普通獲取）的最大數量。基於netty的壓力工具和連接計數

我們之前使用過netty，並且選擇它來編寫這個簡單的測試。這非常簡單，我只用4個小類擴展了netty api（code is here），並且它在本地主機開發機器（linux）上提供了大約30K rps。

主要限制是傳出連接限制（在linux中打開文件/套接字限制），在我的機器上大約是30-40K。在這種情況下，您獲得java.net.BindException。 因此，您必須手動限制傳出netty連接的數量，以防止達到極限時的性能下降。

我實現了這個限制與反，並在第一個版本我增加它在SimpleChannelUpstreamHandler.channelConnected和future.getChannel().getCloseFuture().addListener遞減（見，在註釋放置代碼）並沒有奏效：像預想和反連接失敗並沒有增加。

，僅在我把增量近bootstrap.connect：

connected.incrementAndGet(); 
ChannelFuture future = bootstrap.connect(new InetSocketAddress(host, port));

和減量在SimpleChannelUpstreamHandler.messageReceived：

@Override 
    public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) throws Exception { 
     // the same here - decrementing connections here is not fully fair but works! 
     connected.decrementAndGet(); 
     e.getChannel().close(); 
    }

- 它開始工作。唯一的問題 - 這有點不公平，因爲你可以增加計數器，但無法連接或減少，並且無法在它之後斷開連接。

那麼，爲什麼不反對在正確的版本工作？

更新：試過的建議，INC/DEC在SimpleChannelUpstreamHandler.channelConnected：

@Override 
    public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) throws Exception { 
     // by logic you should count connection here, but in practice - it doesn't work 
     connected.incrementAndGet(); 
     ctx.getChannel().getCloseFuture().addListener(new ChannelFutureListener() { 
      @Override 
      public void operationComplete(ChannelFuture future) throws Exception { 
       connected.decrementAndGet(); 
      } 
     }); 

     e.getChannel().write(GET); 
     sent.incrementAndGet(); 
    }

沒有工作，又在那裏發送>連接不可預測的數字，如：

client1 stat: connected= 0, sent= 0, ERRORS: timeouts= 0, binds= 0, connects=0 
client1 stat: connected= 11, sent= 4990, ERRORS: timeouts= 0, binds= 0, connects=0 
client1 stat: connected= 1, sent= 8591, ERRORS: timeouts= 0, binds= 0, connects=0 
client1 stat: connected= 459, sent=13064, ERRORS: timeouts= 0, binds= 5, connects=0 
client1 stat: connected= 1545, sent= 7234, ERRORS: timeouts= 0, binds= 115, connects=0 
client1 stat: connected= 0, sent=10037, ERRORS: timeouts= 0, binds= 80, connects=0

SADF

來源

2013-04-23 yetanothercoder

理論。

在您的原始版本中，您將遞減已連接的計數器用於所有連接嘗試，發生失敗的計數器。如果在channelConnected（）中增加計數器，並向ChannelCloseFuture添加遞減監聽器，那麼我猜你會得到更好的結果。

這是因爲

boostrap.connect().getChannel().getCloseFuture(...)

總是會調用operationComplete，即使通道從未接通。

更新：

確保只有連接的通道被計數。在channelConnected（）calback在STressClientHandler：

connected.incrementAndGet(); 
    ctx.getChannel().getCloseFuture().addListener(new ChannelFutureListener() { 

     @Override 
     public void operationComplete(ChannelFuture future) throws Exception { 
      connected.decrementAndGet(); 
     } 
    });

來源

2013-04-24 08:50:48

你怎麼建議遞減ChannelCloseFuture計數器？當我描述我想，作爲'future.getChannel（）getCloseFuture（）的addListener（新ChannelFutureListener（）{...'沒有運氣還有另一種選擇 - 服務器端：。。。'SimpleChannelHandler.channelClosed（）'難道你的意思是？ – yetanothercoder 2013-04-25 08:24:16

查看更新.... – 2013-04-25 08:39:05

謝謝，試過，沒有幫助，請參見更新的問題 – yetanothercoder 2013-04-25 14:32:09

您需要OT遞增發送計數被添加到這是從寫（...）操作返回的ChannelFuture一個ChannelFutureListener。否則，即使寫入處於掛起狀態，也會增加它。

來源

2013-04-27 17:41:54

感謝，它是關於一個'sent'計數器，但對於已建立的連接反？這就是這個問題是關於什麼的 – yetanothercoder 2013-04-27 18:24:31

基於netty的壓力工具和連接計數

回答

相關問題