のJMeter 3.0：BeanShellの

Question

対JSR223 + Groovyのあなたは、私がJSR223 +（キャッシング）GroovyとBeanShellのを使用して、何それの理由ていたとき、私は応答時間の違いを理解する助けてくださいでした：

グレーラインは赤JSR223、である - それらインサイドBeanShellの

HTTPプロトコルを介しているProtobufメッセージを送信するコードを持っている：

byte[] data = protobuf.toByteArray(); 
String SESSION = vars.get("SESSION"); 

String url = "http://" + vars.get("SERVER_NAME")+":8080/messages/list"; 
HttpClient client = new DefaultHttpClient(); 
////System.out.println(url); 
HttpPost post = new HttpPost(url); 
HttpEntity entity = new ByteArrayEntity(data); 
post.setEntity(entity); 
post.setHeader(HttpHeaders.CONTENT_TYPE, "application/x-protobuf"); 
post.setHeader(HttpHeaders.ACCEPT,"*/*"); 
post.setHeader(HttpHeaders.ACCEPT_ENCODING,"identity"); 
post.setHeader(HttpHeaders.CONNECTION,"Keep-Alive"); 
post.setHeader(HttpHeaders.USER_AGENT,"UnityPlayer/5.0.3p3 (http://unity3d.com) "); 


post.setHeader("Cookie", "SESSION="+SESSION); 
HttpResponse response=null; 
try { 
    response = client.execute(post); 
} catch (ClientProtocolException e) { 
    // TODO Auto-generated catch block 
    e.printStackTrace(); 
} catch (IOException e) { 
    // TODO Auto-generated catch block 
    e.printStackTrace(); 
} 
ByteArrayOutputStream baos = new ByteArrayOutputStream(); 
response.getEntity().writeTo(baos); 
byte[] b = baos.toByteArray(); 

Answer 1

私はJMeterのv3.0のは、SunのJava 1.8上で実行されていると同じ問題を観察しました。私の見解では、Groovy + JSR223はメモリを大量に消費し、多数の一時オブジェクトとメタクラスオブジェクトを読み込みます。これにより、ガベージコレクションのオーバーヘッドが大幅に増加します。私はGCアルゴリズムとしてG1GCを使用していました。

試験＃1：GCオーバーヘッド - ： - （実装BeanShellの）JSR223 + Javaのグルービー+ JSR223 8つのリクエスト/秒、スループットは60〜80％のCPUとヒープ領域の3ギガバイトを

試験＃2を消費で達成されました大幅に減少し、CPU％は約40〜60％程度でした。しかし、スループットは向上しなかった。 bsh.ForNameメソッドのスレッドロックをたくさん確認しました

テスト＃3：Javaコードが入ったプレーンBeanサンプラー - これが最高でした！スループットはすぐに1秒あたり15000に達し、CPU％は100％に達しました。しかし、オーバーヘッドは負荷によるものです。私はそれを元の負荷の10％減らし、わずか20％のCPUで50req/sec以上を簡単に達成することができました。

上記で行った実験に基づいて、私はJSR223を使用する代わりに、JavaコードでプレーンBeanサンプラーを使用することをお勧めします。