-------------------------------------------------- Apache Tomcatで稼働するWebアプリケーションの一つの画面が、 セッションタイムアウト設定30分でピーク時の同時接続セッションが300のアクセスに耐えられるかの 負荷テストをApache JMeter 5.6を使用して行いたいです。 HTTP Request Samplerの、 Number of Threads, Ramp-up Period, Loop Count の値をそれぞれどのように指定すればよいですか？ -------------------------------------------------- ChatGPTの回答 -------------------------------------------------- 短時間でピーク負荷を掛けるならThreads 300, Ramp-up 30秒, Loop Count:Forever+Duration 10分など 徐々に負荷を上げるならRamp-upを300秒にするなど -------------------------------------------------- Claudeの回答 -------------------------------------------------- Threads 300, Ramp-up 900秒, Duration 1時間 -------------------------------------------------- 「耐えられるか」どうかを判断するうえで必須で行うべき確認項目を洗い出し、 Apache JMeterのどのListenerの何という項目で確認できるかをそれぞれ挙げてください。 -------------------------------------------------- ChatGPT/Claudeの回答 -------------------------------------------------- 【１】平均応答時間、90%のリクエストがクリアする応答時間、最大応答時間 (3〜5秒以内が目安) Summery ReportのAverage,90% Line, Max ※またはView Results in Table Aggregate Reportの90%,95%,99% Line Graph ResultsのAverageの推移 Response Time Graphで時間と共に増大していないかをチェック 【２】エラー率(1%未満が目安) Summary ReportのError % Aggregate ReportのError % View Results Tree: 詳細なエラー内容の特定に使用 Aggregate Graph: エラーの推移 【３】スループット（秒あたり処理できたリクエスト数） Summary ReportのThroughput (スループット [リクエスト数/sec]) Aggregate ReportのThroughput Graph ResultsのThroughputの推移 ※スループットの目標値・目安はどう決める？ ⇒世の中標準というものがあまりないから、実際のログ等からピーク時のアクセス数を知る。 例えば既存環境のピーク時間帯に10分間に6000リクエストが発生していれば、 6000/10/60秒=10リクエスト/秒が裁ける必要があると分かる。 【４】同時ユーザー数に対する負荷の変化(増えても悪化しないこと) Active Threads Over Time Response Time Graph Throughput vs Thread DB Connections 【５】サーバのリソース CPU利用率80%以下が目安 Linuxコマンド top, vmstat, iostat, netstat等 Tomcatの監視 JConsole, JP@GC - CPU Usage AWSなら CloudWatch、RDSモニタリング、ALBのモニタリング -------------------------------------------------- Summery Reportとサーバ側のリソース監視だけでかなりの範囲がカバーできますね。 負荷テストの序盤に、感覚的に耐えられるかどうかだけを判断したい場合は、 まずListenerとしてSummery Reportだけを作成してテストを行い、 懸念事項や課題があるたびに詳細なlistenerを追加する作業順序が良いでしょうか。 それとも、テストしたい項目を網羅できるlistenerをできる限り最初から追加してテストする方が優れた方法ですか。 -------------------------------------------------- 基本はそうです。Summery Reportだけで行い、 応答時間が課題なら Response Time Graph スループットが課題なら Graph Results エラー率なら View Results Tree ユーザー数が増えると悪化するなら Active Threads Over Time を追加して詳しく見る。 -------------------------------------------------- 2025/07/13 -------------------------------------------------- JMeterのレポート以外の物から負荷を分析する方法 -------------------------------------------------- 1. Webサーバー（Tomcat） Tomcatアクセスログ 各リクエストの処理時間、HTTPステータス Tomcatエラーログ Java例外、メモリエラー、リソースエラー (/opt/tomcat/logs/catalina.out または journalctl -u tomcat) CloudWatch メトリクス（EC2） CPU使用率、メモリ使用量、ディスクIO、ネットワーク帯域 AWS コンソール → EC2 → モニタリングタブ 見るべきポイント アクセスログの HTTPステータスコードが500台（エラー）になっていないか？ 処理時間（ログにms単位で記録される）に急激な増加がないか？ エラーログに OutOfMemoryError, SQLException, Connection Timeout などがないか？ CloudWatchで CPU使用率が80%超 になっていないか？ メモリスワップしていないか？ スレッドプール: 接続プールの枯渇を示すエラーメッセージが出ていないか？ 2. データベース メニューシステムのアクセス履歴テーブルのデータ Amazon RDS CloudWatch メトリクス CPU、接続数、クエリレイテンシ、ストレージIO AWS コンソール → RDS → DBインスタンス → モニタリング Oracle Alertログ（自動） システムエラー、メモリエラー RDSでは Amazon RDS > ログとイベント で確認可 V$SESSION / V$SQLモニタリング 見るべきポイント CloudWatchメトリクスの CPUUtilization が80%以上に張り付いていないか？ DatabaseConnections が 最大値近く になっていないか？ ReadLatency や WriteLatency（読み書き遅延）が通常に比べて大きくなっていないか？ Alertログに ORA-, Timeout, Resource Exceeded などのエラーがないか？ 接続プール: コネクションプールの枯渇や接続エラー ロック競合: 長時間のロック待機が発生していないか SQLパフォーマンス: 実行計画の変化や遅いクエリの特定 -- アクティブセッション数 SELECT COUNT(*) FROM v$session WHERE status = 'ACTIVE'; -- 待機イベント（パフォーマンスボトルネック特定） SELECT event, total_waits, time_waited FROM v$system_event WHERE event NOT LIKE 'SQL%Net%' ORDER BY time_waited DESC; -- 実行時間の長いSQL SELECT sql_text, elapsed_time, executions FROM v$sql WHERE elapsed_time > 1000000 -- 1秒以上 ORDER BY elapsed_time DESC; 3. ネットワーク JMeter側の応答時間 レスポンスのばらつきが大きすぎないか Summary Report の 90% Line, Max Direct Connect のモニタリング 帯域使用率、遅延、パケットドロップ AWS コンソール → Direct Connect → 接続 → メトリクス JMeter PC ? AWS間の ping/trace 高遅延・経路異常の兆候がないか ping, traceroute, mtr など（オンプレPCから実行） Packet Loss: パケットロスが発生していないか DirectConnectの Peak Tx, Peak Rx 帯域が設計帯域（例: 1Gbps）に近づいていないか？ Connection State: 接続状態が正常か Bandwidth Utilization: 帯域使用率が上限に近づいていないか RTT（Round Trip Time）（pingの応答時間）が通常より大きく（>100msなど）なっていないか？ 負荷が高い時間帯で 応答時間がネットワーク遅延由来になっていないか？ 4. テスト全体の分析・判断基準まとめ | 観点 | 判断基準 | | --------------- | -------------------------------- | | **応答時間（レスポンス）** | 90%のリクエストが目標応答時間内（例：3秒以内）である | | **HTTPエラー率** | 1%未満が望ましい（JMeter + Tomcatアクセスログ） | | **サーバーリソース** | CPU/メモリ使用率が80%未満、スワップやOOMなし | | **DBメトリクス** | 接続数・CPU・遅延が許容範囲内（CloudWatch） | | **ネットワーク** | Direct Connect帯域に余裕、RTTに異常がない | | **全体の安定性** | スループットが安定、エラーや遅延が徐々に増加していない | 5. 最後に：負荷テスト後のおすすめ作業順序 JMeter Summary Report → スループット・応答時間・エラー率をざっくり把握 Tomcat アクセスログ/エラーログ → アプリ側に異常がなかったか EC2 CloudWatch メトリクス → リソースの過負荷がないか RDS CloudWatch メトリクス + Alertログ → DB処理が遅れていなかったか DirectConnectメトリクス + ping/traceroute → 通信の遅延・輻輳 がないか -------------------------------------------------- 2025/08/02 -------------------------------------------------- Apache JMeterを使用した負荷テスト時間中のAmazon EC2やRDSのインスタンスのリソース負荷状況を、 監視したいと思います。 テスト時間中、AWSコンソールの各インスタンスのメトリクスを目視でずっと見張り続ける以外に、 テスト開始時刻以降の推移を事後に知ることができる計測方法はありますか。 EC2、RDSそれぞれに対して教えてください。 -------------------------------------------------- ◆EC2 標準 テスト期間を時系列で絞ってグラフ化できるので、後から確認可能です。 AWSマネジメントコンソール → CloudWatch → メトリクス → EC2 → インスタンスID メトリクス名 説明 CPUUtilization CPU使用率 NetworkIn/Out 受信・送信ネットワーク量 DiskRead/WriteBytes ディスクI/O量 StatusCheckFailed システムの障害検知 ◆EC2 CloudWatch Agent導入済の場合 EC2に CloudWatch Agent を導入している場合、以下のような詳細メトリクスも確認できます： 追加で収集できるもの 例 メモリ使用率 mem_used_percent スワップ使用量 swap_used プロセス数 procstat_count カスタムアプリ（Tomcat等） CPU時間、スレッド数なども設定可能 ◆RDS 標準 RDSは以下の標準メトリクスを 1分ごと にCloudWatchに送信します： メトリクス名 説明 CPUUtilization CPU使用率 DatabaseConnections DB接続数 FreeableMemory 利用可能メモリ ReadLatency ストレージ読み込み遅延（秒） WriteLatency 書き込み遅延 ReadIOPS/WriteIOPS IOPS テスト開始・終了時刻を指定して、CloudWatch上で事後に可視化可能です。 ◆RDS Enhanced Monitoring（有効化が必要）設定済の場合 OSレベルのリソース状況（プロセス単位、CPU、ネットワークなど）をリアルタイムで1秒〜60秒間隔で記録できます。 取得可能な情報 備考 OSレベルCPU/メモリ DBエンジンでなくOS全体の状態 スレッド数 DBワーカープロセスなど Disk/Network I/O ストレージ性能に影響 有効化： RDSインスタンス → 「変更」→ 「拡張モニタリング」→ 有効（1秒間隔など） Enhanced MonitoringはCloudWatch Logsグループにデータが出力され、後から参照可能 ◆RDS Performance Insights（有効化が必要）設定済の場合 SQLレベルの詳細情報（どのSQLが負荷をかけたか）を時系列で可視化できます。 確認できる内容 詳細 トップSQL 最も重いSQLがどれか Wait Event ロックやI/Oなどの待機イベント DB負荷（AAS） アクティブなDBセッション数 -------------------------------------------------- --------------------------------------------------