きっかけ

レスポンスの問題が発生

Webを介した社内文書検索システム（ユーザー数全国支店社員3,000人）をメインフレームからWindowsサーバー1台に移行した直後、レスポンスが遅くなったとのクレームがユーザーから数多く寄せられました。

システム部門の対応

初めてのJavaを利用

Javaを利用することが初めてであったため、原因はJavaにあると判断されました。開発ベンダーに修正を依頼されましたが問題の特定には至らず、応急処置としてCPU、メモリの増強を検討していました。そこで、IIMに分析の依頼をいただきました。

IIMによる性能分析

各種レスポンス時間（処理時間）の分析

ES/1による性能評価を実施し、チューニングヒントの出力とＳＥコンサルティングを行いました。

Web、ＡＰ、DBのそれぞれのレスポンス時間、処理時間を分析し、想定より遅くなっていないかを確認しました。

遅くなっているところがあれば、その箇所にレスポンス遅延の原因があると考えられるからです。

業務量を確認

業務量の目安となるURL毎のアクセス件数から、「URL_A」へのアクセス件数が一番多いことが確認できました。

URL毎のレスポンス時間を確認

アクセス件数の多いURLほどレスポンスが良好であることが理想です。そのため、上記「URL_A」のレスポンス時間を確認したところ想定より大幅に遅いことがわかりました。

Java処理時間、DB処理時間との相関

上記「URL_A」のレスポンス時間が長いことから、その内訳であるJava処理時間とDB処理時間を確認いたしました。

その結果、「URL_A」レスポンス時間に占めるDBの処理時間が非常に長いことがわかりました。

以上のことから、DB処理の遅延が原因でJava処理の遅延が発生し、結果として「URL_A」のレスポンスが遅延したと考えられます。

システム部門のご判断

Oracleの分析

DB処理にレスポンス悪化の原因があることがわかりましたが、さらに原因を特定するため分析を進めたところ、Oracleのバッファキャッシュヒット率が低下し、実I/Oが発生していることが最終原因と判明しました。

メモリ割当てによる問題解消

メモリの使用状況を確認したところ充分に余裕があったため、Oracleのバッファキャッシュへの割当てを増やしました。バッファキャッシュヒット率を改善することで問題が解決いたしました。

結果

約1,000万円の投資コストを抑制

上記チューニングにより問題は解消されたため、当初検討されていたCPU、メモリの増設は中止されました。その結果、ハードウェア、導入費用、運用費用等を含め、約1,000万円のコスト削減を実現することができました。

もし、当初の目論見に基づきCPUやメモリの拡張を行っていても、期待する効果は得られなかったと想定されます。

本事例のように原因が他に存在するといった事象は、さまざまなベンダーやミドルウェアが混在する環境では、しばしば発生します。

このようなケースでES/1をご利用いただくことで、早期発見・解決にお役に立つことができます。