概要前提条件と制限アーキテクチャツールベストプラクティスエピックトラブルシューティング関連リソース

AWS Blu Age モダナイズされたアプリケーションのパフォーマンスを最適化する

Vishal Jaswani、Manish Roy、Himanshu Sah、Amazon Web Services

概要

AWS Blu Age でモダナイズされたメインフレームアプリケーションは、本番環境にデプロイする前に、機能とパフォーマンスの同等性テストが必要です。パフォーマンステストでは、モダナイズされたアプリケーションは、特に複雑なバッチジョブでは、レガシーシステムよりも動作が遅くなります。この格差が存在するのは、メインフレームアプリケーションがモノリシックであるのに対し、最新のアプリケーションは多層アーキテクチャを使用しているためです。このパターンは、AWS Blu Age で自動リファクタリングを使用してモダナイズされたアプリケーションのパフォーマンスギャップに対処するための最適化手法を示しています。

このパターンでは、ネイティブ Java およびデータベース調整機能を備えた AWS Blu Age モダナイゼーションフレームワークを使用して、パフォーマンスのボトルネックを特定して解決します。このパターンでは、プロファイリングとモニタリングを使用して、SQL 実行時間、メモリ使用率、I/O パターンなどのメトリクスのパフォーマンスの問題を特定する方法について説明します。次に、データベースクエリの再編成、キャッシュ、ビジネスロジックの改良など、ターゲットを絞った最適化を適用する方法について説明します。

バッチ処理時間とシステムリソース使用率の向上により、モダナイズされたシステムのメインフレームパフォーマンスレベルを一致させることができます。このアプローチは、最新のクラウドベースのアーキテクチャへの移行中も機能的同等性を維持します。

このパターンを使用するには、「エピック」セクションの手順に従ってシステムを設定し、パフォーマンスホットスポットを特定し、「アーキテクチャ」セクションで詳しく説明されている最適化手法を適用します。アーキテクチャ

前提条件と制限

前提条件

AWS Blu Age モダナイズされたアプリケーション
JProfiler ライセンス
データベースクライアントとプロファイリングツールをインストールするための管理者権限
AWS Blu Age レベル 3 認定
AWS Blu Age フレームワーク、生成されたコード構造、Java プログラミングに関する中級レベルの理解

制約事項

以下の最適化機能と機能は、このパターンの範囲外です。

アプリケーション層間のネットワークレイテンシーの最適化
Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプとストレージの最適化によるインフラストラクチャレベルの最適化
同時ユーザー負荷テストとストレステスト

製品バージョン

JProfiler バージョン 13.0 以降 (最新バージョンを推奨）
pgAdmin バージョン 8.14 以降

アーキテクチャ

このパターンでは、JProfiler や pgAdmin などのツールを使用して AWS Blu Age アプリケーションのプロファイリング環境を設定します。 AWS Blu Age が提供する DAOManager API と SQLExecutionBuilder APIs による最適化をサポートしています。

このセクションの残りの部分では、モダナイズされたアプリケーションのパフォーマンスホットスポットと最適化戦略を特定するための詳細情報と例を示します。エピックセクションのステップでは、詳細なガイダンスのためにこの情報を参照します。

モダナイズされたメインフレームアプリケーションでのパフォーマンスホットスポットの特定

モダナイズされたメインフレームアプリケーションでは、パフォーマンスホットスポットはコード内の特定の領域であり、大幅な速度低下や非効率を引き起こします。これらのホットスポットは、メインフレームアプリケーションとモダナイズされたアプリケーション間のアーキテクチャ上の違いによって引き起こされることがよくあります。これらのパフォーマンスのボトルネックを特定し、モダナイズされたアプリケーションのパフォーマンスを最適化するには、SQL ログ記録、クエリEXPLAINプラン、JProfiler 分析の 3 つの手法を使用できます。

ホットスポット識別手法: SQL ログ記録

AWS Blu Age を使用してモダナイズされたアプリケーションを含む最新の Java アプリケーションには、SQL クエリをログに記録する機能が組み込まれています。 AWS Blu Age プロジェクトで特定のロガーを有効にして、アプリケーションによって実行される SQL ステートメントを追跡および分析できます。この手法は、バッチ処理やクエリの改良によって最適化される可能性のある、過剰な個々のクエリや構造化されていないデータベース呼び出しなどの非効率的なデータベースアクセスパターンを特定するのに特に役立ちます。

AWS Blu Age モダナイズされたアプリケーションで SQL ログ記録を実装するには、 application.properties ファイル内の SQL ステートメントDEBUGのログレベルをに設定して、クエリ実行の詳細をキャプチャします。


level.org.springframework.beans.factory.support.DefaultListableBeanFactory : WARN
level.com.netfective.bluage.gapwalk.runtime.sort.internal: WARN
level.org.springframework.jdbc.core.StatementCreatorUtils: DEBUG
level.com.netfective.bluage.gapwalk.rt.blu4iv.dao: DEBUG
level.com.fiserv.signature: DEBUG
level.com.netfective.bluage.gapwalk.database.support.central: DEBUG
level.com.netfective.bluage.gapwalk.rt.db.configuration.DatabaseConfiguration: DEBUG
level.com.netfective.bluage.gapwalk.rt.db.DatabaseInteractionLoggerUtils: DEBUG
level.com.netfective.bluage.gapwalk.database.support.AbstractDatabaseSupport: DEBUG
level.com.netfective.bluage.gapwalk.rt: DEBUG

ログに記録されたデータを使用して最適化ターゲットを特定することで、高頻度のクエリとパフォーマンスの低いクエリをモニタリングします。バッチプロセス内のクエリは通常、パフォーマンスへの影響が最も大きいため、それらに焦点を当てます。

ホットスポット識別手法: EXPLAIN 計画をクエリする

このメソッドは、リレーショナルデータベース管理システムのクエリ計画機能を使用します。PostgreSQL や MySQL、Oracle EXPLAINなどのコマンドを使用してEXPLAIN PLAN、データベースが特定のクエリをどのように実行するかを調べることができます。これらのコマンドの出力は、インデックスを使用するか、完全なテーブルスキャンを実行するかなど、クエリ実行戦略に関する貴重なインサイトを提供します。この情報は、クエリのパフォーマンスを最適化するために重要です。特に、適切なインデックス作成によって実行時間が大幅に短縮される場合に重要です。

アプリケーションログから最も反復的な SQL クエリを抽出し、データベースに固有の EXPLAIN コマンドを使用して、パフォーマンスの低いクエリの実行パスを分析します。PostgreSQL データベースの例を次に示します。

クエリ:


SELECT * FROM tenk1 WHERE unique1 < 100;

EXPLAIN コマンド:


EXPLAIN SELECT * FROM tenk1 where unique1 < 100;

出力:


Bitmap Heap Scan on tenk1 (cost=5.06..224.98 rows=100 width=244) 
Recheck Cond: (unique1 < 100) 
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=100 width=0)
Index Cond: (unique1 < 100)

EXPLAIN 出力は次のように解釈できます。

EXPLAIN 計画を最も内側から外側 (下から上) のオペレーションに読み取ります。
主要な用語を探します。たとえば、 Seq Scanはフルテーブルスキャンを示し、はインデックスの使用状況Index Scanを示します。
コスト値を確認する: 最初の数字は起動コスト、2 番目の数字は合計コストです。
推定出力行数rowsの値を参照してください。

この例では、クエリエンジンはインデックススキャンを使用して一致する行を検索し、それらの行 () のみを取得しますBitmap Heap Scan。これは、個々の行アクセスのコストが高いにもかかわらず、テーブル全体をスキャンするよりも効率的です。

EXPLAIN プランの出力のテーブルスキャンオペレーションは、インデックスが欠落していることを示します。最適化には、適切なインデックスを作成する必要があります。

ホットスポット識別手法: JProfiler 分析

JProfiler は包括的な Java プロファイリングツールです。低速のデータベース呼び出しと CPU 負荷の高い呼び出しを特定することで、パフォーマンスのボトルネックを解決できます。このツールは、遅い SQL クエリと非効率的なメモリ使用量を特定するのに特に効果的です。

クエリの分析例：


select evt. com.netfective.bluage.gapwalk.rt.blu4iv.dao.Blu4ivTableManager.queryNonTrasactional

JProfiler ホットスポットビューには、次の情報が表示されます。

時間列
- 合計実行時間 (329 秒など) を表示します。
- 合計アプリケーション時間の割合を表示します (例: 58.7%)
- 最も時間のかかるオペレーションを特定するのに役立ちます
平均時間列
- 実行ごとの期間 (2,692 マイクロ秒など) を表示します。
- 個々のオペレーションパフォーマンスを示します
- 個々のオペレーションが遅いことを検出するのに役立ちます
イベント列
- 実行数を表示します (例: 122,387 回）
- オペレーションの頻度を示します
- 頻繁に呼び出されるメソッドの特定に役立ちます

結果の例：

高頻度: 122,387 回の実行は最適化の可能性を示します
パフォーマンス上の懸念: 平均時間で 2,692 マイクロ秒は非効率を示唆する
重大な影響: 合計時間の 58.7% が重大なボトルネックを示している

JProfiler は、アプリケーションのランタイム動作を分析して、静的コード分析や SQL ログ記録では明らかではない可能性のあるホットスポットを明らかにすることができます。これらのメトリクスは、最適化が必要なオペレーションを特定し、最も効果的な最適化戦略を決定するのに役立ちます。JProfiler の機能の詳細については、JProfiler ドキュメントを参照してください。

これらの 3 つの手法 (SQL ログ記録、クエリEXPLAINプラン、JProfiler) を組み合わせて使用すると、アプリケーションのパフォーマンス特性を包括的に把握できます。最も重要なパフォーマンスホットスポットを特定して対処することで、元のメインフレームアプリケーションとモダナイズされたクラウドベースのシステムの間のパフォーマンスギャップを埋めることができます。

アプリケーションのパフォーマンスホットスポットを特定したら、次のセクションで説明する最適化戦略を適用できます。

メインフレームモダナイゼーションの最適化戦略

このセクションでは、メインフレームシステムからモダナイズされたアプリケーションを最適化するための主要な戦略の概要を説明します。既存の APIs、効果的なキャッシュの実装、ビジネスロジックの最適化の 3 つの戦略に焦点を当てています。

最適化戦略: 既存の APIs

AWS Blu Age は、パフォーマンスを最適化するために使用できる DAO インターフェイスにいくつかの強力な APIs を提供します。DAOManager と SQLExecutionBuilder の 2 つのプライマリインターフェイスは、アプリケーションのパフォーマンスを向上させる機能を提供します。

DAOManager

DAOManager は、モダナイズされたアプリケーションのデータベースオペレーションのプライマリインターフェイスとして機能します。データベースオペレーションを強化し、アプリケーションのパフォーマンスを向上させる複数の方法、特に簡単な作成、読み取り、更新、削除 (CRUD) オペレーションとバッチ処理を提供します。

SetMaxResults を使用します。DAOManager API では、SetMaxResults メソッドを使用して、単一のデータベースオペレーションで取得するレコードの最大数を指定できます。デフォルトでは、DAOManager は一度に 10 個のレコードのみを取得するため、大規模なデータセットを処理するときに複数のデータベース呼び出しが発生する可能性があります。この最適化は、アプリケーションが多数のレコードを処理する必要があり、それらを取得するために現在複数のデータベース呼び出しを実行している場合に使用します。これは、大規模なデータセットを繰り返し処理するバッチ処理シナリオで特に役立ちます。次の例では、左側のコード (最適化前) は、デフォルトのデータ取得値である 10 レコードを使用します。右側のコード (最適化後) は、一度に 100,000 レコードを取得するように setMaxResults を設定します。
注記
より大きなバッチサイズを慎重に選択し、オブジェクトのサイズを確認します。この最適化によりメモリフットプリントが増加するためです。
SetOnGreatorOrEqual を SetOnEqual に置き換えます。この最適化には、レコードを取得するための条件を設定するために使用する方法の変更が含まれます。SetOnGreatorOrEqual メソッドは指定された値以上のレコードを取得しますが、SetOnEqual は指定された値と完全に一致するレコードのみを取得します。
次のコード例に示すように SetOnEqual は、完全一致が必要であり、現在 SetOnGreatorOrEqual メソッドの後に readNextEqual() を使用していることがわかっている場合に使用します。この最適化により、不要なデータの取得が軽減されます。
バッチ書き込みおよび更新オペレーションを使用します。バッチオペレーションを使用して、複数の書き込みまたは更新オペレーションを 1 つのデータベーストランザクションにグループ化できます。これにより、データベース呼び出しの数が減少し、複数のレコードを含むオペレーションのパフォーマンスが大幅に向上します。
次の例では、左側のコードがループで書き込みオペレーションを実行するため、アプリケーションのパフォーマンスが低下します。バッチ書き込みオペレーションを使用してこのコードを最適化できます。WHILEループを反復するたびに、バッチサイズが所定のサイズである 100 に達するまでレコードをバッチに追加します。その後、バッチが所定のバッチサイズに達したときにバッチをフラッシュし、残りのレコードをデータベースにフラッシュできます。これは、更新が必要な大規模なデータセットを処理するシナリオで特に役立ちます。
インデックスを追加します。インデックスの追加は、クエリのパフォーマンスを大幅に向上させるデータベースレベルの最適化です。インデックスを使用すると、データベースはテーブル全体をスキャンすることなく、特定の列値を持つ行をすばやく見つけることができます。WHERE 句、JOIN条件、またはORDER BYステートメントで頻繁に使用される列のインデックス作成を使用します。これは、大きなテーブルや、迅速なデータ取得が重要な場合に特に重要です。

SQLExecutionBuilder

SQLExecutionBuilder は、実行される SQL クエリの制御、特定の列のみの取得、 INSERTの使用SELECT、動的テーブル名の使用に使用できる柔軟な API です。次の例では、SQLExecutorBuilder は定義したカスタムクエリを使用します。

DAOManager と SQLExecutionBuilder の選択

これらの APIsは、特定のユースケースによって異なります。

AWS Blu Age ランタイムで SQL クエリを自分で記述するのではなく生成する場合は、DAOManager を使用します。
データベース固有の機能を活用したり、最適な SQL クエリを記述したりするために SQL クエリを記述する必要がある場合は、SQLExecutionBuilder を選択します。

最適化戦略: キャッシュ

モダナイズされたアプリケーションでは、効果的なキャッシュ戦略を実装することで、データベース呼び出しを大幅に削減し、応答時間を短縮できます。これにより、メインフレーム環境とクラウド環境のパフォーマンスギャップを埋めることができます。

AWS Blu Age アプリケーションでは、シンプルなキャッシュ実装はハッシュマップや配列リストなどの内部データ構造を使用するため、コストとコードの再編成を必要とする外部キャッシュソリューションを設定する必要はありません。このアプローチは、頻繁にアクセスされるが、頻繁に変更されないデータに特に効果的です。キャッシュを実装するときは、メモリの制約と更新パターンを検討して、キャッシュされたデータの一貫性を維持し、実際のパフォーマンス上の利点が得られるようにします。

キャッシュを成功させるための鍵は、キャッシュする適切なデータを特定することです。次の例では、左側のコードは常にテーブルからデータを読み取りますが、ローカルハッシュマップに特定のキーの値がない場合、右側のコードはテーブルからデータを読み取ります。 cacheMapは、プログラムのコンテキストで作成され、プログラムコンテキストのクリーンアップメソッドでクリアされるハッシュマップオブジェクトです。

DAOManager を使用したキャッシュ：

SQLExecutionBuilder を使用したキャッシュ：

最適化戦略: ビジネスロジックの最適化

ビジネスロジックの最適化では、最新のアーキテクチャ機能に合わせて AWS Blu Age から自動生成されたコードを再構築することに重点を置いています。これは、生成されたコードがレガシーメインフレームコードと同じロジック構造を維持している場合に必要になります。これは、最新のシステムには適していない可能性があります。目標は、元のアプリケーションと機能的同等性を維持しながらパフォーマンスを向上させることです。

この最適化アプローチは、単純な API の調整やキャッシュ戦略にとどまりません。これには、アプリケーションがデータを処理し、データベースとやり取りする方法の変更が含まれます。一般的な最適化には、単純な更新のための不要な読み取り操作の回避、冗長なデータベース呼び出しの削除、最新のアプリケーションアーキテクチャとの整合性を高めるためのデータアクセスパターンの再編成などがあります。ここにいくつか例を挙げます。

データベース内のデータを直接更新します。 ループによる複数の DAOManager オペレーションの代わりに直接 SQL 更新を使用して、ビジネスロジックを再構築します。たとえば、次のコード (左側) は複数のデータベース呼び出しを行い、過剰なメモリを使用します。具体的には、ループ内の複数のデータベースの読み取りおよび書き込みオペレーション、バッチ処理ではなく個々の更新、反復ごとに不要なオブジェクトの作成を使用します。
次の最適化されたコード (右側) は、単一の Direct SQL 更新オペレーションを使用します。具体的には、複数の呼び出しの代わりに 1 つのデータベース呼び出しを使用し、すべての更新が 1 つのステートメントで処理されるため、ループは必要ありません。この最適化により、パフォーマンスとリソース使用率が向上し、複雑さが軽減されます。これにより、SQL インジェクションが防止され、クエリプランのキャッシュが改善され、セキュリティが向上します。
注記
SQL インジェクションを防ぎ、適切なトランザクション管理を確保するために、常にパラメータ化されたクエリを使用してください。
冗長データベース呼び出しを削減します。冗長データベース呼び出しは、特にループ内で発生する場合、アプリケーションのパフォーマンスに大きな影響を与える可能性があります。単純で効果的な最適化手法は、同じデータベースクエリを複数回繰り返すのを避けることです。次のコード比較は、retrieve()データベース呼び出しをループ外に移動すると、同一のクエリの冗長実行を防ぎ、効率を向上させる方法を示しています。

SQL 句を使用してデータベース呼び出しを減らしますJOIN。SQLExecutionBuilder を実装して、データベースへの呼び出しを最小限に抑えます。SQLExecutionBuilder は SQL 生成をより細かく制御でき、DAOManager が効率的に処理できない複雑なクエリに特に役立ちます。たとえば、次のコードは複数の DAOManager 呼び出しを使用します。


List<Employee> employees = daoManager.readAll();
for(Employee emp : employees) {
    Department dept = deptManager.readById(emp.getDeptId());  // Additional call for each employee
    Project proj = projManager.readById(emp.getProjId());     // Another call for each employee
    processEmployeeData(emp, dept, proj);
}

最適化コードは、SQLExecutionBuilder で 1 回のデータベース呼び出しを使用します。


SQLExecutionBuilder builder = new SQLExecutionBuilder();
builder.append("SELECT e.*, d.name as dept_name, p.name as proj_name");
builder.append("FROM employee e");
builder.append("JOIN department d ON e.dept_id = d.id");
builder.append("JOIN project p ON e.proj_id = p.id");
builder.append("WHERE e.status = ?", "ACTIVE");

List<Map<String, Object>> results = builder.execute();  // Single database call
for(Map<String, Object> result : results) {
    processComplexData(result);
}

最適化戦略を一緒に使用する

これらの 3 つの戦略は相乗的に機能します。APIsは効率的なデータアクセスのためのツールを提供し、キャッシュはデータ取り出しを繰り返す必要性を減らし、ビジネスロジックの最適化はこれらの APIs を可能な限り最も効果的な方法で使用できるようにします。これらの最適化を定期的にモニタリングおよび調整することで、モダナイズされたアプリケーションの信頼性と機能を維持しながら、パフォーマンスを継続的に向上させることができます。成功の鍵は、アプリケーションの特性とパフォーマンス目標に基づいて各戦略をいつ、どのように適用するかを理解することです。

ツール

JProfiler は、開発者とパフォーマンスエンジニア向けに設計された Java プロファイリングツールです。Java アプリケーションを分析し、パフォーマンスのボトルネック、メモリリーク、スレッドの問題を特定するのに役立ちます。JProfiler は、CPU、メモリ、スレッドプロファイリング、データベースと Java 仮想マシン (JVM) のモニタリングを提供し、アプリケーションの動作に関するインサイトを提供します。
注記
JProfiler の代わりに、Java VisualVM を使用できます。これは、CPU 使用率、メモリ消費量、スレッド管理、ガベージコレクション統計をリアルタイムでモニタリングする Java アプリケーション用の無料のオープンソースのパフォーマンスプロファイリングおよびモニタリングツールです。Java VisualVM は組み込みの JDK ツールであるため、基本的なプロファイリングのニーズに対して JProfiler よりもコスト効率が高くなります。
pgAdmin は、PostgreSQL 用のオープンソースの管理および開発ツールです。データベースオブジェクトの作成、管理、使用を支援するグラフィカルインターフェイスを提供します。pgAdmin を使用すると、単純な SQL クエリの記述から複雑なデータベースの開発まで、さまざまなタスクを実行できます。その機能には、SQL エディタを強調表示する構文、サーバー側のコードエディタ、SQL、シェル、バッチタスクのスケジュールエージェント、初心者と経験豊富な PostgreSQL ユーザーの両方に対するすべての PostgreSQL 機能のサポートが含まれます。

ベストプラクティス

パフォーマンスホットスポットの特定：

最適化を開始する前に、ベースラインパフォーマンスメトリクスを文書化します。
ビジネス要件に基づいて、パフォーマンス改善の明確な目標を設定します。
ベンチマークを行うときは、パフォーマンスに影響する可能性があるため、詳細なログ記録を無効にします。
パフォーマンステストスイートを設定し、定期的に実行します。
pgAdmin の最新バージョンを使用します。（古いバージョンはEXPLAINクエリプランをサポートしていません）。
ベンチマークでは、最適化が完了したら JProfiler をデタッチします。これはレイテンシーが増加するためです。
ベンチマークでは、デバッグモードはレイテンシーが増加するため、必ずデバッグモードではなく開始モードでサーバーを実行してください。

最適化戦略：

application.yaml ファイルで SetMaxResults 値を設定し、システム仕様に従って適切なサイズのバッチを指定します。
データボリュームとメモリの制約に基づいて SetMaxResults 値を設定します。
後続の呼び出しがである場合にのみ、SetOnGreatorOrEqual を SetOnEqual に変更します.readNextEqual()。
バッチ書き込みまたは更新オペレーションでは、設定されたバッチサイズより小さく、書き込みまたは更新オペレーションによって失われる可能性があるため、最後のバッチを個別に処理します。

キャッシュ：

でキャッシュするために導入されるフィールドはprocessImpl、実行ごとに変更され、常にそののコンテキストで定義する必要がありますprocessImpl。また、 doReset()または cleanUp()メソッドを使用してフィールドをクリアする必要があります。
インメモリキャッシュを実装する場合は、キャッシュのサイズを適正化します。メモリに保存されている非常に大きなキャッシュは、すべてのリソースを占有し、アプリケーションの全体的なパフォーマンスに影響を与える可能性があります。

SQLExecutionBuilder:

SQLExecutionBuilder で使用する予定のクエリの場合は、などのキー名を使用しますPROGRAMNAME_STATEMENTNUMBER。
SQLExecutionBuilder を使用する場合は、常に Sqlcodフィールドを確認してください。このフィールドには、クエリが正しく実行されたか、エラーが発生したかを指定する値が含まれています。
SQL インジェクションを防ぐには、パラメータ化されたクエリを使用します。

ビジネスロジックの最適化：

コードを再構築するときは機能的同等性を維持し、関連するプログラムのサブセットに対して回帰テストとデータベース比較を実行します。
比較のためにプロファイリングスナップショットを維持します。

エピック

タスク	説明	必要なスキル
JProfiler をインストールして設定します。	JProfiler ダウンロードページで、オペレーティングシステム (Windows、macOS、または Linux) の JProfiler をダウンロードします。 JProfiler ドキュメントの指示に従ってインストールプロセスを完了します。初期設定を実行します。 JProfiler アプリケーションを起動します。ライセンスキーをアクティブ化します。デフォルトの JVM 設定を構成します。インストールを確認します。 JProfiler を起動します。テストプロファイリングセッションを実行します。手順については、JProfiler ドキュメントの「JVM のプロファイリング」セクションの「ローカルサービスへのアタッチ」を参照してください。 https://www.ej-technologies.com/resources/jprofiler/help/doc/main/profiling.html	アプリ開発者
pgAdmin をインストールして設定します。	このステップでは、データベースをクエリするように DB クライアントをインストールして設定します。このパターンでは、PostgreSQL データベースと pgAdmin をデータベースクライアントとして使用します。別のデータベースエンジンを使用している場合は、対応する DB クライアントのドキュメントに従ってください。 pgAdmin ダウンロードページからオペレーティングシステムの pgAdmin をダウンロードしてインストールします。インストール時にマスターパスワードを設定します。データベースサーバーに接続します。手順については、pgAdmin ドキュメントを参照してください。 pgAdmin クエリツールを使用して基本的な SQL クエリを実行して、インストールを確認します。	アプリ開発者

タスク	説明	必要なスキル
AWS Blu Age アプリケーションで SQL クエリのログ記録を有効にします。	アーキテクチャセクションで説明されているように、 AWS Blu Age アプリケーションの `application.properties` ファイルで SQL クエリログ記録のロガーを有効にします。	アプリ開発者
クエリ`EXPLAIN`プランを生成して分析し、データベースのパフォーマンスホットスポットを特定します。	詳細については、「アーキテクチャ」セクションを参照してください。	アプリ開発者
JProfiler スナップショットを作成して、パフォーマンスの低いテストケースを分析します。	JProfiler を起動します。 JProfiler アプリケーションを開きます。スタートセンターで、クイックアタッチタブを選択します。リストから Tomcat プロセスを選択します。 [開始] を選択します。プロファイリング設定を構成する：推奨サンプリングオプションを選択します。設定画面でデフォルトのオプションを保持し、OK を選択します。接続ステータスがステータスバーに表示されるまで待ちます。パフォーマンスデータを記録します。ツールバーで、録画の開始を選択します。テストケースを実行し、完了するまで待ちます。録画を停止を選択します。スナップショットを保存して表示します。スナップショットの保存を選択します。スナップショットを保存する場所を選択し、保存を選択します。	アプリ開発者
JProfiler スナップショットを分析して、パフォーマンスのボトルネックを特定します。	JProfiler スナップショットを分析するには、次の手順に従います。スナップショットを開きます。ファイル、Open Snapshot を選択します。保存したスナップショットの場所に移動します。新しいウィンドウを開くを選択して分析を開始します。データベースオペレーションを分析します。 JDBC/Database セクションに移動し、JPA/Hibernate タブを選択します。クエリを時間別に確認します (デフォルトのソートオプションです）。最適化する最上位のクエリを選択します。 CPU 使用率を確認します。 CPU セクションで、ホットスポットビューを選択します。最適化の時間パーセンテージで最上位のコードを特定します。繰り返し発生するパターンに注意してください。ホットスポットを特定したら、次のエピックで説明するように、ベースラインを設定し、適切な最適化戦略を実装します。これらの最適化に焦点を当てます。スロークエリの場合は、SQLExecutionBuilder または DAOManager 最適化を使用します。頻繁なデータアクセスには、キャッシュメカニズムを実装します。複雑なビジネスロジックでは、ロジックを簡素化し、データベース呼び出しが多すぎないようにし、単純なクエリを実行してコードを簡素化できるかどうかを判断します。たとえば、コードがテーブル A からテーブル B にデータを挿入する場合、このコードを書き換えて次のような SQL コマンドを実行します。 `INSERT INTO TABLE A SELECT * FROM TABLE B` アプリケーションがパフォーマンス要件を満たすまで、影響の順序 (最高から最低) でコードの分析と最適化を続けます。 JProfiler の使用の詳細については、「アーキテクチャ」セクションとJProfiler ドキュメント」を参照してください。	アプリ開発者

タスク	説明	必要なスキル
最適化を実装する前に、パフォーマンスベースラインを確立します。	初期パフォーマンス測定として、最適化なしでテストケースを実行します。現在の状態の JProfiler スナップショットを作成し、次のメトリクスを文書化します。合計実行時間データベース呼び出しの数 CPU 使用率メモリ使用パターンドキュメントベースラインを作成します。タイムスタンプとテスト条件ですべてのメトリクスを保存します。パフォーマンスに影響を与える可能性のある外部要因に注意してください。最適化後に比較できるように JProfiler スナップショットを保存します。次のエピックで説明されている最適化の変更を計画します。ベースラインメトリクスを確認します。最適化するオペレーションを特定します。現在のコードのバックアップを作成します。期待される改善点を文書化します。実装前に各変更を測定します。ベースライン条件を使用してテストケースを実行します。実行時間を記録します。現在の動作を文書化します。	アプリ開発者

タスク	説明	必要なスキル
読み取り呼び出しを最適化します。	DAOManager SetMaxResults メソッドを使用してデータの取得を最適化します。このアプローチの詳細については、「アーキテクチャ」セクションを参照してください。	アプリ開発者、DAOManager
データベースへの複数回の呼び出しを避けるために、ビジネスロジックをリファクタリングします。	SQL `JOIN`句を使用してデータベース呼び出しを減らします。詳細と例については、「アーキテクチャ」セクションの「ビジネスロジックの最適化」を参照してください。	アプリケーション開発者、SQLExecutionBuilder
コードをリファクタリングしてキャッシュを使用し、読み取り呼び出しのレイテンシーを短縮します。	この手法の詳細については、「アーキテクチャ」セクションの「キャッシュ」を参照してください。	アプリ開発者
複数の DAOManager オペレーションを使用して単純な更新オペレーションを行う非効率的なコードを書き換えます。	データベース内のデータを直接更新する方法の詳細については、「アーキテクチャ」セクションの「ビジネスロジックの最適化」を参照してください。	アプリ開発者

タスク	説明	必要なスキル
機能同等性を維持しながら、各最適化の変更を繰り返し検証します。	最適化を実装した後：設定したベースラインから同じテストケースを実行します。新しい実行時間を記録します。結果がベースライン出力と一致することを確認します。最適化の結果が改善した場合は、実際の利益を文書化し、次の最適化に進みます。問題が見つかった場合は、変更をロールバックし、アプローチを確認して、代替ソリューションを試してください。各変更の進行状況を追跡します。新しいメトリクスをベースラインメトリクスと比較します。改善率を計算します。利益の累計を維持します。注記ベースラインメトリクスをリファレンスとして使用すると、システムの信頼性を維持しながら、各最適化の影響を正確に測定できます。	アプリ開発者

トラブルシューティング

問題	ソリューション
最新のアプリケーションを実行すると、エラーの例外が表示されます`Query_ID not found`。	この問題を解決するには。という名前のファイルがアプリケーションサーバーの作業ディレクトリの `sql`フォルダ`query.sql`に存在するかどうかを確認します。 `.sql` ファイルの名前がプログラム名と一致することを確認します。たとえば、という名前のプログラムの場合`ABC`、ファイル名はである必要があります`ABC.sql`。
インデックスを追加しましたが、パフォーマンスが向上していません。	クエリエンジンがインデックスを使用していることを確認するには、次の手順に従います。 PostgreSQL を使用している場合は、コマンドを実行します`EXPLAIN <sql query>`。 `Seq Scan` またはのコマンドの出力を確認します`Index Scan`。は、インデックスセットが SQL クエリの `where`句が使用している列で使用できない`Seq Scan`ことを意味します。正しい列のセットにインデックスを作成し、作成したインデックスを使用するクエリを作成してみてください。
out-of-memoryの例外が発生しました。	コードがデータ構造によって保持されているメモリを解放していることを確認します。
バッチ書き込みオペレーションにより、テーブルにレコードが欠落する	コードを確認して、バッチ数がゼロでない場合に追加の書き込みオペレーションが実行されていることを確認します。
SQL ログはアプリケーションログに表示されません。	ログ記録設定ファイルの場所と構文を確認します。 `DEBUG` 指定したパッケージのログレベルがに設定されていることを確認します。例: `level.com.netfective.bluage.gapwalk.rt.blu4iv.dao: DEBUG level.org.springframework.jdbc.core: DEBUG` アプリケーションサーバーのログファイルのアクセス許可を確認します。設定の変更後、アプリケーションサーバーを再起動します。