JMeter：BeanShellサンプラーを忘れる

Jmeterで標準のテスト計画要素を使用すると、すべてではなく多くのことができます。 機能を拡張し、より複雑なロジックを実装するには、BeanShell Samplerを使用するのが慣習です。これは、世界中で歴史的に何らかの形で開発されてきました。 そして世界中で彼らは定期的にこれに苦しんでいますが、サボテンを食べ続けています。

彼なしではどうですか？

原則として、ロードステーション自体のパフォーマンスに関して最高の結果を得るには、Javaリクエストを実装するか、独自のサンプラーを作成することも最も効果的です。 しかし、個人的に、私はこのソリューションが好きではありません：

• ソリューションの開発にかかる人件費の増加。
• ソリューションの非透過的なサポート（コードは別の場所にあり、追加のアクションを使用して再コンパイルする必要があります）。
• JMeterが提供する可能性のあるボーナスの損失（たとえば、コードでDBMSへのリクエストを実行し、次にHTTPリクエストを実行した場合、それらは合計ではなく個別に表示されます）。

だから私はいつもそのような決定を避けようとしました（そして今のところ避けました！）。 個人的には、コードがテスト計画自体に含まれているときに気に入っており、JMeterを使用してこのコードを実行するのにかかる時間を追跡できます。 この意味で、BeanShellサンプラーアプローチ自体は非常に便利であり、実装のみが悪いです。 理由を説明します。

悪いBeanShellサンプラーとは

BeanShell Samplerのコード挿入を使用して、高度にロードされたテスト計画を開発しました。 開発段階ではすべて順調でしたが、負荷テストの試用を開始すると、非常に不快な動作が発生しました。 特定の数のスレッドでは、すべてが正常に機能しました。 しかし、スレッド数の増加に伴い、いくつかの不十分さが始まりました。 このテストでは、ターゲットの負荷強度が大幅に不足しており、レポートでは、個々のBeanShellサンプルの処理時間が数十秒に達したことが示されました。 さらに、BeanShellサンプラーは非常に少なく、スレッドグループごとに1つまたは2つであり、そこで複雑なことが起こったとは言いません。 ロードステーション自体のパフォーマンスパラメーターを調べても問題は見つかりませんでした。CPU負荷は20〜30％で、JMeterプロセスに十分なメモリがあり、ガベージコレクターはタイムリーにクリーンアップしました。 問題がJMeterのプログラムコード自体またはBeanShellインタープリターの実装にあることは明らかです。 Daw Reset bsh.Interpreterで遊んでも何も得られません。 それだけではありません。ある場所では、メモリオーバーランがないようにインストールする方が良いと書いており、別の場所では、パフォーマンス上の理由で削除する方が良いと書いています。

そのような問題に関するメッセージは、JMeterフォーラムで時々見られ、Apache JMeter Userメーリングリストに載っています。 同僚も一部のテストの動作について不満を述べていましたが、問題はツール自体に起因する傾向がありました。

どうする

JMeterには、JSR223サンプラーと呼ばれる非常によく似たサンプラーがあります。 サンプラーだけでなく、ファミリー全体：サンプラー、タイマー、プリプロセッサーとポストプロセッサー、アサーション、タイマー、リスナー。 そのサンプラーは、このサンプラーが大幅なパフォーマンスの改善を達成するという非常に心強い言葉で始まります。 しかし、注意深い読者はすぐに動揺します。この効果を達成するには、コンパイルをサポートするスクリプトエンジンを選択する必要があります。 そのすぐ近くで、Javaエンジンがそうではないことが示されています。

Javaについては、さらに言います。BeanShellと同じエンジンで実装されています。 これは、実行可能コードでエラーを発生させることで簡単に確認できます。 ログの例外スタックで、bshインタープリターがそことそこの両方で呼び出されていることがわかります。 したがって、JSR223 / javaとBeanShell Samplerの間にまったく違いはありません。 他のエンジンについては何も言われていませんが、それらもすべて解釈されます。 したがって、標準のJMeterパッケージには、コンパイルによって利益を得ることができるエンジンはありません。

ドキュメントで言及されている唯一のコンパイル済みスクリプトエンジンはGroovyです。 JSR223をサポートする他のエンジンがあります。 私はScalaを試してみましたが、この束がいかにゆっくりと動いているかを恐れ、このトピックをより良い時まで残しました。 （注：ここでのポイントはおそらくScalaではなく、JSR 223標準の実装とCompilableインターフェースの実装です。）

Groovyサポートを有効にするには、プロジェクトのWebサイトまたはこちらからバイナリの最新バージョンをダウンロードする必要があります 。 アーカイブから必要なファイルは、embeddable \ groovy-all- {version} .jarの1つだけです。 Zhimetrのlibフォルダーに解凍します。 プログラムを再起動すると、利用可能なJSR223言語のリストにGroovyが表示されます。







JSR223 + Groovyでのテスト計画のすべてのBeanShellサンプラーを作り直した後、奇跡が起こりました：すべてが正常に（正常に、または少なくともプログラミングしたとおりに）動作し始め、ブレーキなしでCPU負荷がさらに低くなりました。 JSR223サンプラーの応答時間は桁違いに短くなり、テストは必要な負荷に達しました。

Groovyパフォーマンス

始めに戻った場合-追加のソフトウェアロジックを実装するさまざまな方法-Groovyを使用したソリューションは、実際にパーセンテージを絞る必要がある場合を除き、ほとんどすべての場合に十分なはずです。 Groovyスクリプトは、通常のJavaバイトコードにコンパイルされ、ネイティブJavaコードであるかのように各スレッドのコンテキストで実行されます（ただし、独自のコンパイラーがあり、エンジンを呼び出すためのオーバーヘッドがまだあることに注意してください）。 Blazemeterの関係者は、さまざまな実装オプションの速度を比較し、Groovyコードの速度はpure Javaのコードに比べてわずかに劣るという結論に達しました。

私も少し実験をしました。 整数演算で人工的な計算を実行する小さなフラグメントを作成しました。

int i; int s = Integer.parseInt(Parameters); for (i = 1; i < 10000; i++) { s += i * (i % 2 * 2 - 1); } log.warn(s.toString());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

入力データ（パラメーター）とログへの依存性は、念のために追加されました。これは、実行を完全に除外したり、結果をキャッシュしたりする、トリッキーなコンパイラーとインタープリターがコードを最適化するのを防ぐためです。 さらに、パラメータもユニークでした。 1000反復の100スレッドを備えたCore i7を搭載したラップトップでは、各結果は次のとおりでした。

実装	スループット
Beanshellサンプラー	〜20 /秒
JSR223 +（java | beanshell | bsh）	〜20 /秒
JSR223 + Groovy	〜13800 /秒

Groovyのギャップは非常に大きいため、信じることすら困難ですが、ログから判断すると、すべてが正常に機能していました。

GroovyのサブセットとしてのJava

Groovyの大きな利点は、95％のケースで、任意のJavaコードが有効なGroovyコードであることです。 BeanShell構文でさえ、現在のJava標準からさらに離れています（たとえば、BeanShellでは、任意の数の引数を使用して関数を呼び出す場合は、変更する必要があります）。 現時点ですべての可能性を学習することに興味がない場合は、その必要はありません。 一方、あなたがそれをマスターすれば、あなたは確実にあなたの効果を高めることができるでしょう。

bsh.shared

BeanShellでグローバル名前空間bsh.sharedを使用した場合、小さな待ち伏せがあります。Groovyにはこの種のものは何もありません。 幸いなことに、この問題は自分で簡単に解決できます。 このために、10行のコードが記述されています。

 import java.util.concurrent.ConcurrentHashMap; public class SharedHashMap { private static final ConcurrentHashMap instance = new ConcurrentHashMap(); public static ConcurrentHashMap GetInstance() { return instance; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、これはシングルトンであり、常に（各スレッドに対して）同じオブジェクトを返します。 さらに、jarに収集され、Zhimetrのlibフォルダーに配置されます。 クラスはグローバル名前空間で宣言されているので（そう、これは非難されます）、Groovyコードではインポートせずに、SharedHashMapを使用してそこに何かを置くことができます。

 //     hash map. sharedHashMap = SharedHashMap.GetInstance() //   -. sharedHashMap.put('Counter', new java.util.concurrent.atomic.AtomicInteger())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

あなたが拾う必要があるとき、同様に：

 sharedHashMap = SharedHashMap.GetInstance() // * counter = sharedHashMap.get('Counter') counter.incrementAndGet() //..
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

* Groovyは、セミコロンと同様に変数の型を宣言する必要はありません。

BeanShell Samplerを使用した移行

すでに多くのBeanShellサンプラーが含まれているテスト計画が既にあり、問題があるためにこの記事を見つけたとします。 Groovyに切り替えます。 Groovy接続は上記で説明されており、5分以内に完了します。

まず、JSR223サンプラーを作成し、BeanShellからコードを転送します。 コードを統合し、[ファイル名]フィールドで指定することで別のファイルで選択できる場合、生活を大幅に簡素化できます。 次に、コピー/貼り付けを使用して、JSR223サンプラーを適切な場所に貼り付けるだけです。 そうでない場合は、それぞれの場合にBeanShellからコードをコピーします。

キャッシングキー

ここで重要なのは、JMeterがサンプラー自体に入力されたコードをコンパイルするのは、コンパイルキーが指定されている場合のみです（Compilation Cache Keyフィールド）。 テスト計画内で一意の行である必要があります。 ファイルを介して接続されたスクリプトの場合、ファイルへのフルパスを使用するため、コンパイルキーを入力する必要はありません。

JavaとGroovyの文字列

Groovy構文には微妙な点が1つあります。 まず、2種類の文字列があります。

• 二重引用符-Groovy文字列
• 単一引用符で囲んだ-Java文字列

詳細はこちらをご覧ください。 Groovyストリングには、$ {expression}などの式を使用する機能があります。この式は、ストリング内で式値に自動的に展開されます。 これは非常に便利なポイントですが、意外にもJMeter変数を参照する構文と一致します。 だからGroovyで書くと

 currId = 123 log.info("Current ID: ${currId}")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同時に、currIdという名前の通常のJMeter変数が現在のスレッドで定義され、その値がスクリプトに直接代入されます。 また、1回置換されます。 その後、コードがコンパイルされ、結果がキャッシュされます。 したがって、このような式で使用される変数名がJMeter変数と重複しないようにする必要があります。 また、本当に値をJSR223サンプラーに渡す必要がある場合は、このためにParametersフィールドを使用する必要があります。







外部ファイルをソースコードとして使用する場合、JMeter変数置換は発生しません（フィールドでのみ発生します）が、パラメーターを使用できます。

Groovy文字列の機能を使用する予定がない場合は、Java文字列を使用することをお勧めします（つまり、単一引用符で囲みます）。 また、パフォーマンスは向上しますが、もちろん1ペニーです。

おわりに

BeanShellサンプラーの動作は、一般的なインタープリターの問題、つまりインタープリターコードの速度が遅いことを示しています。 BeanShellに数行しかない場合は、おそらく問題に気付かないでしょうが、多くのコードがある場合やループがある場合には間違いなく気付くでしょう。 LoadRunnerインタープリターでもまったく同じ問題が観察されました。

これまでにBeanShellを使用したテストの実行に問題がなかった場合は、今後安全にプレイし、自分でテストを作成しないことをお勧めします。 代わりに、JSR223 + Groovyをすぐに使用することをお勧めします。これにより、ロードステーションでパフォーマンスの問題が発生する可能性が低くなります。



記事から取り出す重要なポイント。

• BeanShell Samplerは使用しないでください。代わりに、JSR223 + Groovyを使用します。
• JSR223 + java =同じBeanShellなので、セクション1を参照してください。
• 複数のJSR223のコードを統合できる場合は、外部ファイルを使用します。 コードの重複を排除すること自体が優れたプログラミングスタイルであるという事実に加えて、Compilation Cache Keyについて心配する必要はありません。
• 組み込みのサンプラースクリプトを使用する場合は、Compilation Cache Keyを忘れないでください。
• bsh.sharedの類似物が必要な場合は、上記のソリューションを使用します。