2025.04.11

#26 機能追加による負荷テスト時の分析事例のご紹介

ES/1 CSシリーズ

ES/1 Shelty

分析事例

今回は、オープンシステム向け性能管理ツール「ES/1 NEO CS」と次世代型エンタープライズシステム向け性能管理ツール「ES/1 Shelty」を活用し、性能分析した事例を紹介します。

分析の背景と観点

背景

お客様の開発部門ご担当者様より、「アプリケーションの機能追加が本番システムに与える影響について」分析してほしいとの

ご依頼を頂きました。

分析の観点と実施手順

分析の観点は実施した負荷テストのリソース使用状況は想定通りか、機能追加が本番機に与える影響の2点です。

これらの観点を、下記①～④の手順で、検証機と本番機のデータを使用し、分析を実施しました。

【検証機】

1. ① 検証機で追加機能の負荷テスト

2. ② 負荷テスト時の分析、改善点の洗い出し

3. ③ 改善後、再度負荷テストと分析

4.  

【本番機】

④ ②と③の負荷テスト結果と本番システムの稼働実績より、機能追加後の負荷をシミュレーション

分析結果

ここからは、検証機及び、本番機それぞれにおける分析結果の詳細をお伝えします。

検証機での負荷テストの内容と分析結果

・負荷テストのシナリオ

　検証機では、業務ピーク時のアクセス負荷を100とし、50%、100%、200%の3パターンで負荷を掛けたシナリオを実行

・分析の観点

　‐応答時間：目標値（3秒以内）に収まっているか

　‐リソース：想定範囲内の負荷であるか

　‐ミドルウェアの稼働に問題がないか

・分析結果

　‐応答時間→3秒以内で問題なし

　‐リソース→CPU、メモリ、I/Oともに想定内の負荷のため問題なし

　‐ミドルウェア→Oracleヒット率が想定外の稼働であること、負荷の高いSQLが実行されていることを発見

・お客様にてチューニングの実施

　ミドルウェアの結果に対して下記のチューニングを実施

　‐テストシナリオと実行の順番を変更

　‐SQLの変更を実施

・再検証のための負荷テスト時の分析結果

　‐テストシナリオを変更して再実行後、想定通りのOracleヒット率になっていることを確認

　‐SQLの変更後、SQL総実行時間が改善され、且つテスト結果にも影響を及ぼしていないことを確認

【検証機】負荷テストの分析詳細

ここでは、負荷テストの分析とチューニング後の結果の詳細をお伝えします。

①応答時間

　応答時間が目標値の3秒以内に収まっていることを確認しました。(図1)

(図1)負荷テスト時に流れた全トランザクションの応答時間

　図1から負荷テストで流れた全トランザクションにおいて、応答時間は3秒以内であることが確認できます。

　また、最大応答時間(1,912ms)はURL①　18:59:50~18:59:52に流れたトランザクションであることも確認できます。

②リソースの使用状況

負荷テスト時のリソース(CPU/メモリ/IO)は問題ないことを確認しました。(図2~4)

(図2).CPU使用率

図2からCPU使用率は60%～80%であるため、問題ないことが確認できます。

(図3).メモリ使用量とページング

図3からメモリは約10GBの空きがあり、ページアウトも多発していないため問題ないことが確認できます。

(図4).デバイスのレスポンス時間

図4から10ms前後のレスポンス時間であるため、問題ないことが確認できます。

③ミドルウェアの稼働状況

ミドルウェアではJavaとOracleの稼働の詳細を確認しました。

Oracleの稼働において、シナリオ毎にキャッシュをクリアしているにも拘らず、バッファキャッシュヒット率に違いが出ていることが判明しました。こちらは想定外の稼働であった為、テストシナリオと順番を変更し、再実行したところ、すべてのシナリオで同等のバッファキャッシュヒット率となり、問題ないことを確認しました。（図5)

(図5).Oracleの稼働比較

④負荷の高いSQLを洗い出し

また、負荷テスト時に実行されたSQLの一覧を負荷率順にソートし確認したところ、負荷が高いSQLにおいて想定外の稼働をするものが存在していることに気づき、該当するSQLの最適化を実施いただきました(図6) 

(図6).負荷テスト時に流れたSQL一覧

その後、最適化されたSQLの稼働を比較したところ、総実行時間が約75%削減されていることを確認しました。(図7)

(図7).SQL変更後の稼働比較

【本番機】機能追加後の負荷分析の内容と結果

本番機では、「ES/1 NEO CS」により取得したピーク時の稼働実績を、検証機では、「ES/1 Shelty」により取得した負荷テスト時の稼働実績、これらのデータを掛け合わせ、機能追加時の負荷予測を実施しました。

・分析の観点

　‐リソース使用率：本番機のリソースに機能追加分のリソース負荷が増加しても問題がないか

　‐JVMメモリ：本番機のヒープに機能追加分のヒープ量が増加しても問題がないか

・分析結果

　‐CPU使用率→機能追加後もCPU使用率は問題なし

　‐JVMメモリ→ヒープメモリが枯渇する可能性を指摘

【本番機】機能追加後の負荷分析詳細

①ピーク時のリソース使用率の比較

本番機のピーク時におけるCPU使用率に機能追加時のCPU負荷率を追加し、シミュレーションしたところ、CPU使用率に問題がないことを確認しました。(図8~9)

(図8).機能追加によってCPUにかかる負荷の想定

図8からCPU使用率においては、テスト①の範囲で最大10％前後の負荷がかかることが想定できます。

(図9).本番機のCPU負荷をシミュレーション

図9から業務ピーク月におけるAP1,AP2の最大CPU使用率は40％以下を推移していることが確認できます。

このことから、機能追加によって本番機のCPUに10％前後の負荷がかかっても問題がないことが確認できます。

②ヒープ使用量の想定

JVMヒープでは、GC発生のタイミングから、どの程度メモリを消費するかを確認したところ、機能追加を実施した場合、ヒープメモリが枯渇する可能性があることをお伝えしました。(図10~11)

現在の本番機では、ヒープサイズを拡張している為、機能追加しても問題ないことを確認しています。

(図10).機能追加によるJavaヒープ使用量の最大値

(図11).本番機のヒープ使用量をシミュレーション

図11はピーク日における本番機のヒープ使用量に機能追加分の600MBを追加したグラフです。

このグラフから、一時的にヒープ使用量が最大値に達している時間帯が確認できます。一時的なヒープの増加に対応するために、本番機のヒープサイズを増やす、もしくは、機能追加で利用するヒープ使用量を削減する必要があることをお伝えしました。

お客様からの声

お客様からは今後の機能追加時の負荷テストだけでなく、リリース後の本番機の監視においてもES/1 Sheltyを活用していきたいとの声を頂きました。

今回の事例が、開発部隊の方々が担当されるであろう機能追加時の負荷テストの可視化や、本番環境での運用の最適化のお役に立ちましたら幸いです。

執筆者

N.N.　

営業技術本部 技術サービス統括部 技術サービス2部　

お客様担当SEとして、製品の構築から活用方法までの一連のサポートを担当
お客様環境にて性能問題が発生した際には、製品のアウトプットを利用し、問題解決に向けた調査／提案業務を実施

 

経歴
2022年　　　　入社
2022年10月~ 　西日本でのお客さまサポートを担当

 

システムリソース情報からの性能管理サポートや、APM製品を利用したユーザー体感レスポンスやアプリケーション視点での性能管理サポートに従事。
現在に至る。