2017-08-21 51 views
1

これは、JMETERツールを使用してREST APIをテストし、スループットをチェックすることに関するものです。JBOSS wildfly 10 Jmeterを使用したパフォーマンスチューニング

JMETERツールを使用するのはかなり新しいです。

私のアプリケーションには、いくつかの条件に基づいてXLSファイルをJSON形式のデータに変換する簡単なREST APIがあります。 これはサーバー(WildFly V10)上で実行されます。私のJMeterの中

構成:スレッドの
数:1000
ランプアップ時間:10
ループ数:1つの

スループットは毎秒10〜12本のヒットで一定のまま。

下記のように私はまた、異なるサブシステムのためのstandalone.xmlファイルにJBOSSのwildflyサーバ10のためのいくつかの構成設定をした:

1) Configuring undertow subsystem: 
modified the default max http connections from 10 to 100 till 1000 
<http-listener name="default" **max-connections="1000"** socket-binding="http" redirect-socket="https" enable-http2="true" buffer-pipelined-data="true" /> 

2) Setting io subsystem: 
configured io-threads and max-threads from 10 to 100 till 1000 
<worker name="default" **io-threads="100" task-max-threads="100"** /> 

3) Configured standalone.conf file for JAVA VM options 
OLD: JAVA_OPTS="-Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true" 
NEW: **JAVA_OPTS="-Xms1024m -Xmx1024m -XX:MaxPermSize=256m** -XX:NewRatio=2 -XX:PermSize=64m -Djava.net.preferIPv4Stack=true" 

4) Configuring infinispan subsystem: 
which has a <cache-container> to configure the thread pool execute in the thread subsystems. It governs the allocation and execution of runnable tasks in the replication queue. 

5) Tried running my application on remote system having **64 GB RAM** and the 3rd configuration mentioned above. 

6) Configuring high value for core threads in JCA subsystem 
**<core-threads count="50"/>** in subsystem urn:jboss:domain:jca:4.0 

をすべてのこれらの設定は、私は、スループットの向上に役立ちdidntの。

JMETERでテストしたときにサーバーのスループットを向上させるために、実際に変更または構成する必要があることを理解してもらえますか?

+0

ランプアップ時間= 0に設定すると、すべてのリクエストが同時に送信されます – user7294900

+0

https://stackoverflow.com/questions/5018846/testing-with-jmeter-how-to-runも参照してください-n-requests-per-second/5786999#5786999 – user7294900

+0

こんにちはuser7294900、 Ramp-upTime = 0で試しましたが、スループットは5-6ヒット/秒に減少しました。要約レポート: –

答えて

1

あまりにも多くの可能な理由がありますが、私はほんの数、最も一般的な提言をリストアップします:JBossを稼動

  1. あなたのマシンは単にオーバーロードされますと、原因CPUまたはフリーRAMまたは集中スワッピングの陳腐不足に迅速に対応することはできませんまたは何でも。テストの実行中にテストリソースの下にあるアプリケーションを監視することで、システムリソースの使用率の増加に伴う負荷の増加を関連付けることはできますが、応答時間の遅れがシステムリソースの不足と結びついているかどうかを判断できますハードウェア容量。 JMeter PerfMon Pluginを使用してJMeterテストとモニタリングを統合することができます。プラグインのインストールと使用の詳細については、How to Monitor Your Server Health & Performance During a JMeter Load Testを参照してください。
  2. JMeterロードジェネレータは、スループットメトリックと同じ影響を受けます。JMeterがテスト中のアプリケーションが速く応答できない場合がありますので、JMeter自体がボトルネックであるため、JMeter Best Practicesに従っていることを確認し、ハードウェアリソースの観点から十分なヘッドルームを確保してください。メトリックが90%のしきい値を超えた場合、JMeterロードジェネレータに同じ監視を適用し、CPU、RAM、ネットワーク、ディスク使用量に注意してください。これは単一のJMeterインスタンスで達成できる最大負荷です。
  3. 負荷テストを再実行しますが、今回はプロファイラツールテレメトリ(たとえばJProfilerまたはYourKit)を使用すると、コードのどの部分が最適化を必要としているかを特定できるように、リソースと時間のかかる方法が最も多く表示されます。
関連する問題