APIのリストを実行している間にJMeterで次のエラーが発生する（スレッド数が1〜140で、ランプアップ期間が1）。JMeterのスレッドで実行している場合の応答コード500
Response code:500
Response message: Internal Server Error
正確な応答を得るためにこのエラー応答コードをどのように克服する必要がありますか？ このレスポンスコードのレスポンス量を減らすにはどうすればよいですか？
一般的に、500は開発者側の未対応の応答です。通常、バックエンドだけでなく、パフォーマンステストツールのフロントエンドにも適用されます。
自分自身に質問してください。適切な内容のサーバーから返された応答を検証していますか？私は、HTTP200が有効であることを示唆するだけではありません。レスポンス・コンテンツがビジネス・プロセスに有効であることを確認するには、レスポンス・コンテンツをチェックする必要があります。完全な有効なHTTP200クラス・ページには、ビジネス・プロセスをレールから外すレスポンスが含まれています。予期せぬ応答の部分で例外を処理しない場合、ビジネスプロセスで1〜2ステップ進んでいくと、要求が完全にコンテキスト外であるため、500を見つけることがほぼ保証されますその時点でのアプリケーションの状態と比較します。
Test101では、すべてのステップについて、ビジネスプロセスを続行できると期待され、肯定的な結果があります。結果が真であることがわからないときは、その結果をチェックし、コードを分岐します。
これがシングルステップのビジネスプロセスであれば、サービスの不十分なデータを渡す可能性が高く、開発者は不十分なデータを処理するうまい部分を完全にはめ込んでいません。
JMeterにおける一般的なアドバイスは、スレッドのランプアップ=数で、あなたのケースでは140
スタートスレッドのランプアップ=数とし、必要に応じて上下に調整します。
現在、あなたはほぼ同時にあるごとに140分の1秒新しいスレッドを送信している、変化に理由がある：
ランプアップが大きすぎるワーク・を回避するのに十分長くする必要がありますテスト開始時の負荷
ステータスコード - 500はサーバー/ APIのものであり、Jmeterの問題ではありません。私の場合、サーバーチームにサーバーの拡張を依頼し、基盤となるAPIをテストできるようにしました。場合によってはJmeterのメモリが不足することもあります。 jmeter execubleファイルのset HEAP=-Xms512m -Xmx512mプロパティで微調整を行うことができます。また、リスナーはリソースを大量に消費します。使用しないでください。
アプリケーションでフォームを保存して読み込むためにJMeterを実行するときにも同じエラーが発生します。手動で操作しても同じエラーは発生しません。 Application Server側からは問題ありません。 – susmitha