| Oracle® Fusion Middleware DICOMコンポーネントの構成と使用 11g リリース1 (11.1.1) E49669-02 |
|
 前 |
 次 |
この項では、この機能から最適なパフォーマンスを得る方法について説明します。
機能のパフォーマンスは、実装における異なる使用方法のシナリオによって直接影響を受けることがあります。この項では、パフォーマンスに影響する可能性のある異なる要素について説明します。
チェックイン構成オプションごとにDICOMコンポーネントがコンテンツ・サーバーに挿入できる1秒当たりの画像の数(固定サイズの画像)。
DICOMアダプタがDICOMクライアントに提供できる1秒当たりの画像の数(固定サイズの画像)。
DICOMアダプタがDICOMクライアントから取得できる1秒当たりの画像の数(固定サイズの画像)。
この機能のパフォーマンスは、次の要素から影響を受ける可能性があります。
コンテンツ・サーバーのレスポンス時間
DICOMクライアントのレスポンス時間
管理対象DICOMクライアントの数
各管理対象クライアントのポーリング間隔
DICOM画像のサイズ
次のリストは、いくつかの主な使用方法のシナリオを示しています(各シナリオのパフォーマンスへの影響に関する説明が続きます)。
DICOMクローラは、PACSなどの管理対象DICOMクライアントのセットを問い合せて新しい画像を取得し、DICOMアダプタは、DICOMコンポーネントを使用してその画像をコンテンツ・サーバーにチェックインします。
DICOMアダプタは、DICOMビューアなどの別のDICOMクライアントからの問合せに応答し、コンテンツ・サーバーに格納されている適切な画像およびメタデータを検索して、その結果セットをDICOMクライアントに戻します。
WebCenter Contentアプリケーションは、DICOMコンポーネントを使用して、コンテンツ・サーバーにDICOM画像を直接チェックインします。
WebCenter Contentアプリケーションは、DICOMコンポーネントを使用して、コンテンツ・サーバーに.jpegファイルなどのDICOM以外のソース画像および対応するDICOM XMLメタデータをチェックインすることで、新しいDICOM画像を作成します。
WebCenter Contentアプリケーションは、コンテンツ・サーバーを直接問い合せ、DICOMコンポーネントを使用して、チェックインしたDICOM画像を検索および取得します。
HTTPクライアントは、WADOプロキシを問い合せ、コンテンツ・サーバーが画像メタデータのみを管理している(ただし、元の画像はPACSに格納されている) DICOM画像をWADO形式のURLを通じて取得します。
次のリストは、異なるシナリオのパフォーマンスへの影響を示しています。
シナリオ1: パフォーマンスは、前述のパフォーマンス要素のすべてから影響を受けます。この場合、DICOMクローラとDICOMアダプタは、DICOMクライアントおよびWebCenter Contentの両方と通信する必要があります。したがって、パフォーマンスはシステムの応答性に影響を受けます。DICOMコンポーネントは、追加されたそれぞれの画像を処理する必要があるため、画像のサイズは、サムネイル生成、メタデータ抽出、チェックイン時間などの処理に影響を与えます。また、多数の管理対象DICOMクライアントが存在する場合、それらのクライアントの数は、システムに対する負荷(および各クライアントに対するポーリング頻度)に影響します。
シナリオ2: DICOMアダプタは、コンテンツ・サーバーに問合せを発行し、適切なDICOM画像データまたはメタデータを取得して、その結果セットをDICOMクライアントに戻す必要があります。パフォーマンスは、主に、コンテンツ・サーバーのレスポンス時間(検索レスポンスおよびデータ交換)とDICOMクライアントのレスポンス時間から影響を受けます。画像データをコンテンツ・サーバーとDICOMクライアントの間で転送する必要があるため、DICOM画像のサイズも影響します。
シナリオ3および4: DICOMコンポーネントは、チェックインに指定されている着信DICOM画像を処理する必要があります(シナリオ4では最初にDICOM画像が生成されます)。サービスは、DICOM画像の処理を担当します。たとえば、サービスは、構成オプションやサービス・パラメータに応じて、特定のDICOM画像からメタデータを抽出したり、そのサムネイル画像を生成する必要があります。このシナリオにおけるパフォーマンス上の主な考慮事項は、コンテンツ・サーバーのレスポンス時間とDICOM画像のサイズです。
シナリオ5: WebCenter Contentアプリケーションは、コンテンツ・サーバーを直接問い合せて、DICOMコンポーネントによって(またはDICOMアダプタから間接的に)チェックインされたDICOM画像コンテンツ(またはメタデータ)を取得します。パフォーマンス上の考慮事項は、コンテンツ・サーバーから任意のタイプの画像を取得する場合と同様です。
シナリオ6: HTTPクライアントは、WADOプロキシを問い合せて、PACSなどのDICOMクライアントに格納されているDICOM画像を取得します。この場合、WADOプロキシは、最初にDICOMリクエストを発行してDICOMクライアントから画像を取得し、次にHTTPクライアントのリクエストに応答してその画像データをクライアントに戻します。このタイプのリクエストのパフォーマンスは、DICOMクライアントの応答性および画像のサイズに影響を受けます。
チューニング可能なパフォーマンス属性の1つは、管理対象DICOMクライアントのポーリング間隔です(2.3.2項「DICOMクローラの構成」を参照)。管理対象DICOMクライアントごとに、この間隔によって、最後の問合せを開始した後で新しい画像をDICOMクライアントに問い合せる前にDICOMクローラが待機する必要のある時間を指定します。このパラメータの値を小さくすると、DICOMクライアントへの問合せ頻度が高くなるため、システム、ネットワークおよびDICOMクライアントに対する負荷が増加します。
このパラメータをチューニングする場合、チェックインされた新しい画像を検索で使用できるようにするため、状況に応じてコンテンツ・サーバーの索引付け間隔を変更する必要があります。
もう1つのチューニング可能なパフォーマンス属性は、チェックイン時にDICOMコンポーネントによって保持または生成するデータを制御するオプションです。次のオプションがあります。
元のDICOM画像の保持
コンテンツ・サーバーに画像をチェックインしないメタデータのみのチェックイン。コンテンツ・サーバーのメタデータ・フィールドのみが移入されます。
画像プレビューの生成
DICOM XMLメタデータの生成
メタデータのみのチェックイン・オプションは、チェックインでは最高のパフォーマンスを得ることができますが、画像の取得では最高のパフォーマンスを得られないことがあります(この場合、コンテンツ・サーバーに元の画像を格納する方が優れています)。どちらの場合でも、画像プレビューの生成とDICOM XMLメタデータの生成は、チェックインのパフォーマンスにのみ影響を与えます。
DICOMアダプタ・スイートを管理するコンテンツ・サーバーの管理者(またはユーザー)は、管理対象DICOMクライアントのポーリング間隔をチューニングして、管理対象DICOMクライアントの応答性と負荷を調整する必要があります。特定の設定において各コンポーネントでDICOMクライアントにどの程度の負荷をかけるかについては、ユーザーごとに好みがあるため、チューニングを自動的に実行することはできません。
管理者またはユーザーは、DICOM画像のチェックイン・オプションをチューニングする必要もあります。状況によっては、画像プレビューまたはDICOM XMLメタデータ生成(あるいはその両方)の機能を使用したり、製品がインストールされているサイトで特定のストレージの問題に対応する必要があるため、この値を自動的にチューニングすることはできません。
