| Oracle® Fusion Middleware Oracle TopLinkソリューション・ガイド 11g リリース1 (11.1.1) B66616-01 |
|
 前 |
 次 |
この章では、TopLinkのパフォーマンス機能およびTopLinkが有効なアプリケーションの監視方法および最適化方法を説明します。
この章には次の項が含まれます:
Toplinkには、多くのパフォーマンス機能が含まれているので、業界で最高のパフォーマンスと最高のスケーラビリティを備えたJPA実装を提供できます。次の機能が含まれています。
TopLinkキャッシュは、クラスと主キーの値に基づいて最近読み取られたり書き込まれたオブジェクトが格納される、インメモリー・リポジトリです。キャッシュは、最近の読取りまたは書込みオブジェクトを保持し、メモリー内でそれらにアクセスしてデータベースへのアクセスを最小限にすることで、パフォーマンスの向上を助けます。
キャッシングでは、次のことを行えます。
キャッシュの無効化と呼ばれるプロセスで、キャッシュの存続期間および時間を設定できます。
キャッシュ・タイプ(Weak、Soft、SoftCache、HardCache、Full)をエンティティごとに構成できます。
エンティティごとにキャッシュ・サイズを構成できます。
クラスタ化されたキャッシュを調整できます。
TopLinkには、次のエンティティ・キャッシング注釈が定義されています。
@Cache
@TimeOfDay
@ExistenceChecking
TopLinkには、TopLinkキャッシュを構成するために指定できる永続性ユニットのプロパティも多数用意されています(http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#How_to_Use_the_Persistence_Unit_Properties_for_CachingにあるEclipseLinkオンライン・ドキュメントの『How to Use the Persistence Unit Properties for Caching』を参照)。これらのプロパティを注釈のかわりに使用したり、注釈を補完したりできる場合があります。
TopLinkでは、パフォーマンスの向上およびオブジェクト・アイデンティティの保持のために、アイデンティティ・マップを使用してオブジェクトがキャッシュされます。エンティティ・クラスで@Cache注釈を使用すれば、キャッシュおよびその動作を制御できます。例9-1に、この注釈の実装方法を示します。
例9-1 @Cache注釈の使用
@Entity @Table(name="EMPLOYEE") @Cache ( type=CacheType.WEAK, isolated=false, expiry=600000, alwaysRefresh=true, disableHits=true, coordinationType=INVALIDATE_CHANGED_OBJECTS ) public class Employee implements Serializable { ... }
オブジェクト・キャッシングおよび@Cache注釈の使用の詳細は、次のEclipseLinkオンライン・ドキュメントの『Using EclipseLink JPA Extensions for Entity Caching』を参照してください。
問合せの範囲、返されるデータ量、およびデータが返される方法はすべて、TopLinkが有効になっているアプリケーションのパフォーマンスに影響を与える可能性があります。Toplinkの問合せメカニズムでは、次の機能を提供して問合せパフォーマンスを向上しています。
この項では、これらの機能により、どのようにパフォーマンスが向上するかを説明します。
TopLinkでは、eclipselink.read-onlyヒント、QueryHint (@QueryHint)を使用して、読取り専用の結果を問合せから取得します。リクエストされたエンティティ・タイプが共有キャッシュにストアされるような非トランザクションの読取り操作の場合は、デタッチされたコピーではなく、共有インスタンスが返されるようにリクエストできます。
読取り専用問合せの詳細は、次の読取り専用ヒントのドキュメントを参照してください。
http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#Read_Only
結合フェッチでは、ソース・オブジェクトと同じ問合せにある関連オブジェクトの結合および読取りを有効にすることにより、パフォーマンスを向上します。例9-2に示すように、@JoinFetch注釈を使用して、結合フェッチを有効にします。この例では、EmployeeフィールドmanagedEmployeesを@JoinFetch注釈で指定する方法を示しています。
例9-2 結合フェッチの有効化
@Entity
public class Employee implements Serializable {
...
@OneToMany(cascade=ALL, mappedBy="owner")
@JoinFetch(value=OUTER)
public Collection<Employee> getManagedEmployees() {
return managedEmployees;
}
...
}
結合フェッチの詳細は、次のEclipseLinkオンライン・ドキュメントの『How to Use the @JoinFetch Annotation』を参照してください。
eclipselink.batchヒントは、TopLinkにバッチ処理情報を提供します。これにより、関連するオブジェクトに対する後続の問合せがバッチ内で最適化されるため、オブジェクトを1つずつ取得したり、大規模な1つの結合読取りで取得したりすることを回避できます。バッチ読取りでは、重複データの読取りが回避されるので、結合よりも効率的です。バッチ処理は、SELECT句にオブジェクトが1つしかない問合せに対してのみ実行できます。
多数のオブジェクトを返す大規模な問合せがある場合は、選択条件を満たすために必要なデータベースのヒット数を減らすことにより、パフォーマンスを向上できます。これを行うには、eclipselink.jdbc.fetch-sizeヒントを使用します。このヒントには、より多くの行が必要になる場合(JDBCドライバのサポート・レベルに従って)に、データベースからフェッチする行数を指定します。ほとんどのJDBCドライバのデフォルト・フェッチ・サイズは10になっています。そのため、1000個のオブジェクトを読み取る場合、フェッチ・サイズを256に増やすと、問合せ結果のフェッチに要する時間が大幅に短縮される場合があります。最適なフェッチ・サイズが常に明白であるとはかぎりません。通常は、予想される総結果サイズの半分または4分の1がフェッチ・サイズとして最適です。結果セットのサイズが不確かな場合に、誤ってフェッチ・サイズの設定を大きく、または小さくしすぎると、パフォーマンスが低下する可能性がありますので、注意してください。
ページング処理が遅いと、アプリケーションの負荷が大幅に高くなる場合があります。ただし、TopLinkには次のようなページング結果が向上する様々な解決策が用意されています。
問合せの実行時に最初に取得する行数および最大行数を構成できます。
基準と一致するすべてのID値に対してデータベースで問合せを実行してから、ID値を使用して特定のセットを取得できます。
問合せヒントを使用して、ScrollableCursorオブジェクトを問合せから返すようにTopLinkを構成できます。これにより、問合せの結果セットにデータベース・カーソルが返されるので、クライアントでページごとに結果をスクロールできるようになります。
ページング・パフォーマンスの向上の詳細は、次のEclipseLinkオンライン・ドキュメントの『How to use EclipseLink Pagination』を参照してください。
http://wiki.eclipse.org/EclipseLink/Examples/JPA/Pagination#How_to_use_EclipseLink_Pagination
TopLinkでは、永続性ユニット全体を範囲とする共有キャッシュ・メカニズムを使用しています。特定の永続性コンテキストで操作が完了すると、結果が共有キャッシュに再びマージされて、他の永続性コンテキストが使用できるようになります。これは、エンティティ・マネージャおよび永続性コンテキストがJava SEまたはJava EEで作成されているかどうかに関係なく行われます。エンティティ・マネージャを使用して永続化または削除されたエンティティでは、常にキャッシュとの整合性が保たれます。
eclipselink.cache-usageヒントを使用すれば、問合せとTopLinkキャッシュとの相互作用の方法を指定できます。詳細は、次のEclipseLinkオンライン・ドキュメントの『Cache Usage』を参照してください。
http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#Cache_Usage
マッピング・パフォーマンスは次の機能で拡張されています。
この項では、これらの機能を説明します。
デフォルトでは、永続オブジェクトが取得される際に、そのオブジェクトが参照する従属オブジェクトがすべて取得されます。リレーションシップ・マッピングによってマップされた属性に対してインダイレクション(遅延ロード、遅延読取りおよびジャストインタイム読取りとも呼びます)を構成すると、参照オブジェクトのプレースホルダとしてインダイレクション・オブジェクトが使用されます。その属性にアクセスするまで、従属オブジェクトの読取りは遅延されます。その結果、アプリケーションにとって重要なのは取得されたオブジェクトの内容のみであり、関連オブジェクトの内容は重要でないという場合は特に、パフォーマンスが大幅に向上します。
TopLinkは、Value Holderインダイレクション、透過インダイレクト・コンテナ・インダイレクション、およびプロキシ・インダイレクションなど、様々なタイプのインダイレクションをサポートします。
クラスを読取り専用に宣言すると、そのクラスのクローンの作成もマージも行われないので、パフォーマンスが大幅に向上します。addReadOnlyClass()を使用すれば、作業ユニットのコンテキスト内でクラスを読取り専用として宣言できます。
単一の作業ユニットに対して読取り専用クラスを構成するには、そのクラスをaddReadOnlyClass()の引数として指定します。
myUnitofWork.addReadOnlyClass(B.class);
複数のクラスを読取り専用に構成するには、それらのクラスをベクトルに追加して、そのベクトルをaddReadOnlyClass()の引数として指定します。
myUnitOfWork.addReadOnlyClasses(myVectorOfClasses);
読取り専用オブジェクトを使用してパフォーマンスを向上する方法の詳細は、次のEclipseLinkオンライン・ドキュメントの『Declaring Read-Only Classes』を参照してください。
http://wiki.eclipse.org/Using_Advanced_Unit_of_Work_API_%28ELUG%29#Declaring_Read-Only_Classes
ウィービングは、コンパイル済のJavaクラスのバイトコードを操作する方法です。TopLink JPA永続性プロバイダでは、ウィービングを使用して、遅延ロード、変更追跡、フェッチ・グループ、内部最適化などに対して、JPAエンティティとPlain Old Java Object (POJO)クラスの両方を拡張します。ウィービングは、実行時の動的実行、エンティティのロード時の実行、エンティティの.classファイルの後処理によるコンパイル時の静的実行のいずれかで実行できます。TopLinkのデフォルトでは、可能な場合は常に動的ウィービングが使用されます。これは、TopLinkエージェントの構成時に、Java EE 5/6アプリケーション・サーバー内およびJava SEに含まれています。動的ウィービングは構成しやすく、プロジェクトのビルド・プロセスを変更する必要がないので、動的ウィービングをお薦めします。
ウィービングを使用してアプリケーションのパフォーマンスを向上する方法の詳細は、次のEclipseLinkオンライン・ドキュメントの『Weaving』を参照してください。
http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Performance/Weaving
データ・トランザクション時のパフォーマンスを最適化するには、変更追跡を使用します。変更追跡では、トランザクション中に発生した変更をTopLinkが検出する方法をチューニングできます。エンティティ・タイプが異なると、アクセス・パターンも設定も異なるので、エンティティ・タイプの使用パターンおよびデータ変更パターンに基づいて方式を選択します。
例9-3に示すように、@ChangeTracking注釈を使用して、変更追跡を有効にします。
例9-3 変更追跡の有効化
@Entity
@Table(name="EMPLOYEE")
@ChangeTracking(OBJECT) (
public class Employee implements Serializable {
...
}
変更追跡の詳細は、次のEclipseLinkオンライン・ドキュメントの『Using EclipseLink JPA Extensions for Tracking Changes』を参照してください。
TopLinkのデータベース・パフォーマンス機能には、次のようなものがあります。
この項では、これらの機能を説明します。
データ・ソースへの接続の確立には時間がかかるため、接続プールにある接続を再使用すれば、パフォーマンスを向上できます。TopLinkは、接続プールを使用して、サーバーおよびクライアント・セッションで使用される接続を管理および共有します。この機能により、必要な接続数が減り、アプリケーションで多くのクライアントをサポートできるようになります。
デフォルトでは、TopLinkセッションは内部接続プールを使用します。これらのプールでは、表示専用でデータの変更が頻繁ではないデータを読み取るアプリケーション用の読取り接続の作成を最適化できます。また、ワークベンチを使用して、デフォルト(書込み)および読取りの接続プールを構成したり、オブジェクト・アイデンティティまたは他の目的のために追加の接続プールを作成することもできます。
内部接続プールに加えて、次のいずれかのタイプの接続プールを使用するようにTopLinkを構成することもできます。
外部接続プール。外部トランザクション・コントローラ(JTA)と統合するには、このタイプの接続プールを使用する必要があります。
デフォルト(書込み)および読取り接続プール。
シーケンス接続プール。表順序付け(つまり、非ネイティブ順序付け)が必要なアプリケーションで、外部トランザクション・コントローラを使用している場合には、これらのタイプのプールを使用します。アプリケーション固有の接続プール。TopLinkの内部接続プールをセッションで使用している場合は、アプリケーションの目的に従って、これらの接続プールを作成して使用できます。
TopLinkで接続プールを使用する方法の詳細は、EclipseLinkオンライン・ドキュメントの次のトピックを参照してください。
Connection Pools
http://wiki.eclipse.org/Introduction_to_Data_Access_%28ELUG%29#Connection_Pools
Introduction to the Internal Connection Pool Creation
パラメータ化されたSQLを使用すれば、SQL問合せの全体の長さが、JDBCドライバまたはデータベース・サーバーで決められた文の長さ制限を超えることを防げます。パラメータ化されたSQLをプリコンパイル文のキャッシュとともに使用すると、コール頻度の高い問合せのSQLがデータベースのSQLエンジンによって解析およびプリコンパイルされる回数が減少し、パフォーマンスが向上します。
デフォルトでは、TopLinkはパラメータ使用のSQLは有効にしますが、プリコンパイルされたSQL文のキャッシュは有効にしません。内部接続プールの使用時はTopLinkで、外部接続プールの使用時はデータ・ソースで、文のキャッシュを有効にし、アプリケーションに適した文のキャッシュ・サイズを指定する必要があります。
パラメータ化されたSQLを有効にするには、ドメイン・クラスと同じパスにあるpersistence.xmlファイルに次の行を追加します。
<property name="eclipselink.jdbc.bind-parameters" value="true"/>
パラメータ化されたSQLを無効にするには、value=をfalseに変更します。
パラメータ化されたSQLおよびSQL文のキャッシュの詳細は、次のEclipseLinkオンライン・ドキュメントの『How to Use Parameterized SQL (Parameter Binding) and Prepared Statement Caching for Optimization』を参照してください。
バッチ書込みは、複数の書込み操作があるトランザクションの最適化に役立ちます。バッチ書込みは、TopLinkのJDBC拡張機能のbatch-writingを使用して有効にします。デプロイ時に、次のパラメータのいずれかを、セッションのこのプロパティに設定してください。
JDBC: JDBCのバッチ書込みを使用します。
Buffered: JDBCのバッチ書込みもネイティブ・プラットフォームのバッチ書込みも使用しません。
Oracle-JDBC: JDBCのバッチ書込みとOracleネイティブ・プラットフォームのバッチ書込みの両方を使用し、プロパティ・マップでOracleJDBCを使用します。
None: バッチ書込みを無効にします。
バッチ書込みの詳細は、次のEclipseLinkオンライン・ドキュメントの『How to Use EclipseLink JPA Extensions for JDBC Connection Communication』を参照してください。
9.2項「TopLinkが有効なアプリケーションの監視および最適化」に説明されているように、TopLinkには監視ツールと最適化ツールが用意されています。
パフォーマンス・チューニングにおける最も重要な課題は、最適化の対象を知ることです。アプリケーションのパフォーマンスを向上させるには、アプリケーションの中で稼働時の効率が最大に達していない領域を特定します。この項では、次のことを説明します。
Oracle TopLinkには、アプリケーションのパフォーマンスを測定し、最適化するための様々な機能が用意されています。ほとんどの機能はディスクリプタまたはセッションで有効または無効にできるので、向上したパフォーマンスをグローバルに適用できます。開発サイクルのどの段階でもパフォーマンスを考慮する必要があります。これは、設計および実装作業の中でパフォーマンスの問題を認識していることを意味しますが、最初の試みで最高のパフォーマンスを達成する必要があるわけではありません。
たとえば、最適化によって設計が複雑になる場合は、最適化作業を最終的な開発フェーズに回します。それでも、後の統合が簡単になるように、最初の段階から最適化の計画を立てることは必要です。
TopLinkアプリケーションのチューニングに関連した最も重要な概念は、対話方式という考え方です。アプリケーションをチューニングする最も効果的な方法は、次のタスクを実行することです:
TopLinkパフォーマンス・プロファイラは、指定のセッション内で実行されたすべての問合せのパフォーマンス統計をロギングすることにより、パフォーマンスの問題を識別するために役立ちます。
TopLinkパフォーマンス・プロファイラでは、次の情報がログ・ファイルに記録されます。
表9-1 TopLinkパフォーマンス・プロファイラでログに記録される情報
| ログに記録される情報 | 説明 |
|---|---|
|
問合せクラス |
問合せクラス名。 |
|
ドメイン・クラス |
ドメイン・クラス名。 |
|
合計時間 |
ネストされた問合せを含む、問合せの合計実行時間(ミリ秒)。 |
|
ローカル時間 |
ネストされた問合せを除く、問合せの実行時間(ミリ秒)。 |
|
オブジェクト数 |
影響を受けたオブジェクトの合計数。 |
|
1秒当たりのオブジェクト処理数 |
トランザクション時に一秒当たりに処理されたオブジェクト数。 |
|
ロギング |
ロギング・メッセージの出力に費やされた時間(ミリ秒)。 |
|
SQL準備 |
SQLスクリプトの準備に費やされた時間(ミリ秒)。 |
|
SQL実行 |
SQLスクリプトの実行に費やされた時間(ミリ秒)。 |
|
行フェッチ |
データベースからの行のフェッチに費やされた時間(ミリ秒) |
|
キャッシュ |
オブジェクト・キャッシュの検索または更新に費やされた時間(ミリ秒) |
|
オブジェクト・ビルド |
ドメイン・オブジェクトの作成に費やされた時間(ミリ秒) |
|
問合せ準備 |
実行する前に問合せの準備に費やされた時間(ミリ秒) |
|
SQL生成 |
SQLスクリプトをデータベースに送信する前にSQLスクリプトの生成に費やされた時間(ミリ秒) |
TopLinkパフォーマンス・プロファイラは、org.eclipse.persistence.tools.profiler.PerformanceProfilerクラスのインスタンスです。有効にするには、次の行をpersistence.xmlファイルに追加します。
<property name="eclipselink.profiler" value="PerformanceProfiler.logProfiler"/>
TopLinkプロファイラの有効化に加えて、PerformanceProfilerクラスのパブリックAPIでも、表9-2で説明する機能が提供されています。
表9-2 PerformanceProfilerの追加機能
| 目的 | 使用するメソッド |
|---|---|
|
プロファイラを無効にします。 |
|
|
操作統計などの各操作プロファイルのすべてのサマリーに、プロファイラがログインするように編成します。操作統計にはプロファイリングされたすべての操作の最短時間、すべての操作の合計時間、プロファイリングされた問合せによって返されたオブジェクトの数、プロファイリングされた各種操作に要した合計時間などがあります。 |
|
|
プロファイラ・ログを、各操作プロファイルを問合せ別にまとめたサマリーとして編成します。 |
|
|
プロファイラ・ログを、各操作プロファイルをクラス別にまとめたサマリーとして編成します。 |
|
プロファイリングの結果は、メモ帳などのテキスト・エディタでプロファイル・ログを開けば表示できます。
プロファイラ出力ファイルには、TopLinkが有効なアプリケーションのヘルスが示されています。
例9-4にTopLinkのプロファイラ出力サンプルを示します。
例9-4 パフォーマンス・プロファイラの出力
Begin Profile of{
ReadAllQuery(com.demos.employee.domain.Employee)
Profile(ReadAllQuery,# of obj=12, time=139923809,sql execute=21723809,
prepare=49523809, row fetch=39023809, time/obj=11623809,obj/sec=8)
} End Profile
例9-4に、問合せに関する次の情報を示します。
ReadAllQuery(com.demos.employee.domain.Employee): プロファイリングした問合せとその引数
Profile(ReadAllQuery): プロファイルの開始と問合せのタイプ
# of obj=12: 問合せに関与したオブジェクトの数
time=139923809: 問合せの合計実行時間(ミリ秒)
sql execute=21723809: SQL文の実行に要した合計時間
prepare=49523809: SQL文の準備に要した合計時間
row fetch=39023809: データベースからの行のフェッチに要した合計時間
time/obj=116123809: 各オブジェクトで要した時間(ナノ秒)
obj/sec=8: 1秒当たりのオブジェクト処理数
アプリケーションでパフォーマンスの問題が起こる可能性のある部分は、次のとおりです。
一般的なパフォーマンスの最適化の識別
スキーマ
マッピングおよびディスクリプタ
セッション
キャッシュ
データ・アクセス
問合せ
作業ユニット
アプリケーション・サーバーとデータベースの最適化
「タスク3: パフォーマンスが悪いアプリケーション・コンポーネントの変更」では、これらの各領域に対処するための簡単なガイドラインを説明します。
9.2.3項「タスク2: アプリケーションのパフォーマンス問題の原因特定」に示されているアプリケーションのパフォーマンス問題の各原因に対して、この項で説明されている回避策を試みることができます。
アプリケーションで必要な場合を除き、TopLinkのデフォルト動作をオーバーライドしないでください。デフォルトの中には、開発環境に適したものがあります。そのようなデフォルトについては、本番環境に合わせて変更してください(http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_%28ELUG%29#Optimizing_for_a_Production_EnvironmentにあるEclipseLinkオンライン・ドキュメントの『Optimizing for a Production Environment』を参照)。
手動でコーディングするのではなく、ワークベンチを使用してください。これらのツールは使用しやすいだけでなく、デプロイXML(および必要に応じて生成されたコード)にエクスポートされるデフォルト構成は、ほとんどのアプリケーションに対して最適化されたベスト・プラクティスを示します。
データベース・スキーマおよびオブジェクト・モデルを設定する際には、最適化を考慮することが重要です。パフォーマンスの問題のほとんどは、オブジェクト・モデルやデータベース・スキーマが複雑すぎて、データベースが遅く、問合せが難しい場合に発生します。これが発生する可能性が高いのは、複雑なオブジェクト・モデルからデータベース・スキーマを直接導出した場合です。
パフォーマンスを最適化するには、オブジェクト・モデルとデータベース・スキーマを一緒に設計します。ただし、各モデルを最適に設計してください。これら2つが1対1に対応する必要はありません。
EclipseLinkオンライン・ドキュメントの『Optimizing Schema』(http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_%28ELUG%29#Optimizing_Schema)には、目的とするパフォーマンスを実現するスキーマを設計するために役立つ4つのスキーマ最適化シナリオが説明されています。
マッピングおよびディスクリプタにパフォーマンスのボトルネックが見つかった場合は、次の解決策を試みてください。
常にインダイレクション(遅延ロード)を使用します。インダイレクションは、最適化するデータベース・アクセスでクリティカルであるだけでなく、これによってキャッシュ・アクセスおよび作業ユニットの処理の最適化など、TopLinkでその他複数の最適化を実行できます。次のEclipseLinkオンライン・ドキュメントの『Configuring Indirection (Lazy Loading)』を参照してください。
http://wiki.eclipse.org/Configuring_a_Mapping_%28ELUG%29#Configuring_Indirection_.28Lazy_Loading.29
TopLinkのマッピングでメソッド・アクセスを使用しないようにします。特に、getメソッドまたはsetメソッドに負荷の高い、または副次的な危険性のあるコードが存在する場合は、メソッド・アクセスのかわりにデフォルトの属性アクセスを直接使用してください。次のEclipseLinkオンライン・ドキュメントの『Configuring Method or Direct Field Accessing at the Mapping Level』を参照してください。
アプリケーションで必要な場合以外は、存在チェック・オプションcheckCacheThenDatabaseをディスクリプタで使用しないようにします。デフォルトの存在チェック動作の方がパフォーマンスに優れています。次のEclipseLinkオンライン・ドキュメントの『Configuring Cache Existence Checking at the Descriptor Level』を参照してください。
TopLinkでオブジェクトのインスタンス化に使用するデフォルト・コンストラクタで、初期化に高い負荷をかけないようにします。そのかわりに、遅延初期化またはTopLinkのインスタンス化ポリシーを使用してディスクリプタを構成し、別のコンストラクタを使用します。次のEclipseLinkオンライン・ドキュメントの『Configuring Instantiation Policy』を参照してください。
http://wiki.eclipse.org/Configuring_a_Descriptor_%28ELUG%29#Configuring_Instantiation_Policy
セッションのパフォーマンスがアプリケーションの妨げになっている可能性がある場合は、次の解決策を試みてください。
データベース・セッションではなく、サーバー環境のサーバー・セッションを使用します。
リモート・セッションではなく、TopLinkのクライアント・セッションを使用します。クライアント・セッションは、ほとんどのマルチユーザーJava EEアプリケーション・サーバー環境に適しています。
クライアント・セッションをプールしないでください。セッションをプールしても、パフォーマンスは向上しません。
セッションの読取り/書込み接続プールのサイズを同時スレッド数に適した値(50など)に増やします。この構成は、内部接続プールの使用時はTopLinkで、外部接続プールの使用時はデータ・ソースで行えます。
その他の参考資料のリストは、次のEclipseLinkオンライン・ドキュメントの『Optimizing Sessions』を参照してください。
http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_%28ELUG%29#Optimizing_Sessions
多くの場合、キャッシュ・コーディネーションを実装すると、キャッシュ・パフォーマンスを向上できます。キャッシュ・コーディネーションでは、分散される可能性のある複数のセッションのインスタンスが相互にオブジェクト変更を送信できるようになるので、各セッションのキャッシュは最新の状態を保つことができます。キャッシュ動作の最適化の詳細は、次のEclipseLinkオンライン・ドキュメントの『Optimizing Cache』を参照してください。
http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_%28ELUG%29#Optimizing_Cache
TopLinkでは、自分のアプリケーションからアクセスするデータ・ソースのタイプによって、低レベルのデータ読取りと書込みのパフォーマンス調整に使用できる、様々なLoginオプションを提供します。より高レベルのデータの読取りおよび書込みの最適化の詳細は、『Optimizing Data Access』(http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_%28ELUG%29#Optimizing_Data_AccessのEclipseLinkオンライン・ドキュメント)に、アプリケーションのデータ・アクセス・パフォーマンスを向上させる方法がいくつか説明されています。そこでは、次の方法が説明されています。
JDBCドライバ・プロパティの最適化
データ形式の最適化
バッチ書込みを使用した最適化
外部結合読取りと継承先サブクラスの使用
パラメータ化されたSQL(パラメータ・バインド)とプリコンパイルされたSQL文のキャッシュを使用した最適化
TopLinkでは、データの読取り、書込みおよび更新用の問合せAPIを幅広く提供しています。『Optimizing Queries』(http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_%28ELUG%29#Optimizing_QueriesのEclipseLinkオンライン・ドキュメント)には、アプリケーションの問合せパフォーマンスを向上させる方法がいくつか説明されています。そこでは、次の方法が説明されています。
パラメータ化されたSQLとプリコンパイルされたSQL文のキャッシュを使用した最適化
名前付き問合せを使用した最適化
バッチ読取りと結合読取りを使用した最適化
部分オブジェクト問合せとフェッチ・グループを使用した最適化
読取り専用問合せを使用した最適化
JDBCフェッチ・サイズを使用した最適化
カーソル付きストリームとスクロール可能カーソルを使用した最適化
結果セットのページ区切りを使用した最適化
ここには、読取りおよび書込みの最適化の例へのリンクも示されています。
作業ユニットを使用する際に最高のパフォーマンスを得るため、次のヒントを検討してください。
オブジェクトを作業ユニットに登録するのは、オブジェクトが変更対象である場合にかぎります。変更されないオブジェクトを登録すると、作業ユニットは不必要にそのオブジェクトをクローン化して処理することになります。
新規または既存のオブジェクトを登録する際には、存在チェックの負荷を回避します。詳細は、次のEclipseLinkドキュメントの『How to Use Registration and Existence Checking』を参照してください。
変更されないとわかっているクラスについては、そのクラスが読取り専用であることを作業ユニットに指示し、チェンジ・セット計算の負荷を回避します。詳細は、次のEclipseLinkオンライン・ドキュメントの『Declaring Read-Only Classes』を参照してください。
http://wiki.eclipse.org/Using_Advanced_Unit_of_Work_API_%28ELUG%29#Declaring_Read-Only_Classes
作業ユニットでReadAllQueryによって読み取られるオブジェクトを変更する予定がない場合は、そのオブジェクトを登録解除し、チェンジ・セット計算の負荷を回避します。詳細は、次のEclipseLinkオンライン・ドキュメントの『How to Unregister Working Clones』を参照してください。
http://wiki.eclipse.org/Using_Advanced_Unit_of_Work_API_%28ELUG%29#How_to_Unregister_Working_Clones
一致する問合せを使用する前に、それが必要であることを確認します。代替方法は、次のEclipseLinkオンライン・ドキュメントの『Using Conforming Queries and Descriptors』を参照してください。
ウィービングと変更追跡を有効にすると、トランザクションのパフォーマンスを大幅に向上できます。詳細は、次のEclipseLinkオンライン・ドキュメントの『Optimizing Using Weaving』を参照してください。
http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_%28ELUG%29#Optimizing_Using_Weaving
パフォーマンスの測定で、作業ユニットのコミット中にパフォーマンスの問題があることを示している場合は、関連するオブジェクトのタイプとその一般的な変更方法に応じて、オブジェクト・レベルまたは属性レベル変更追跡の使用を検討してください。詳細は、次のEclipseLinkオンライン・ドキュメントの『Unit of Work and Change Policy』を参照してください。
アプリケーション・サーバーおよびデータベースのパフォーマンスを最適化するために、次の方法を検討してください。
アプリケーション・サーバーおよびデータベースを正しく構成すると、パフォーマンスおよびスケーラビリティに大きく影響する場合があります。TopLinkアプリケーションおよび永続性の他に、アプリケーションのこれらの主要コンポーネントを正しく最適化していることを確認してください。
アプリケーション・サーバーまたはJava EEサーバーの場合は、メモリー、スレッド・プール・サイズおよび接続プール・サイズが、サーバーで予測されるロードに十分であり、JVMの構成が最適であることを確認します。
最適なパフォーマンスと予測されるロードに対応できるように、データベースが正しく構成されていることを確認します。
最後に、パフォーマンスのボトルネックになっている可能性のある場所を特定して、それらに対処した後、プロファイラを有効にしてアプリケーションを再実行します(9.2.2.1項「TopLinkプロファイラの有効化」を参照)。結果を検討し、さらに処置が必要な場合は、9.2.4項「タスク3: パフォーマンスが悪いアプリケーション・コンポーネントの変更」に示されている手順に従います。
