InterSystems Ensemble® は、HL7メッセージの高速処理機能を備えた迅速なインテグレーションおよび開発プラットフォームです。米国における著名な医療ITのアナリスト組織であるKLAS社^注1による医療分野のインターフェースエンジン部門の調査で、2006年から毎年No.1、または No.2 に位置づけられています。

インターシステムズは、Ensemble 2010.2(メンテナンスリリース 1)で、HL7 v.2 メッセージングに焦点をあてたパフォーマンスと拡張性のベンチマークテストを行いました。この文書では、このテストで示したEnsembleの特性について説明しています。また、EnsembleをHL7v2メッセージングのためのインターフェースエンジンとして使用するシステムの一般的な構成とサイズについてのガイドラインを記します。

このベンチマークは、実際の環境と非常に近いワークロードをシミュレートして行われました。シミュレーションの詳細は「ワークロードの説明と方法」の項目で説明しています。テストされたワークロードは、変換と再ルーティングを含むHL7v2 患者管理（ADT）と、観察報告（ORU）の負荷を含んでいます。

表１：Ensemble 2010.2 のHL7メッセージ維持率（1日当たり）

表１が示すように、テストを行った12コアシステム上で、1日当たり（10時間以上）、インバウンドとアウトバウンドを合わせて5800万以上ものメッセージが維持可能であることが実証されました。ワークロードについては、本文書の「T4ワークロード」の項目で説明しています。ここでは、ルーティングエンジンを使用し、4つの各送信先に、変更されたメッセージを別々に送信しています。

テスト全体において、Ensembleは、FIFO(ファーストイン・ファーストアウト)順の処理を維持し、かつインバウンド、アウトバウンドメッセージのメッセージやキューを全て永続化するよう構成されました。キューとメッセージに永続性を与えることで、Ensemble は、システムクラッシュが起きた場合、データを保護し、全てのメッセージに対する完全な検索と再送信機能を提供します。

さらに、構成のガイドラインについてはこの文章の参考資料に記載されています。このガイドラインは、実際のワークロードに必要なパフォーマンスと拡張性が得られる構成と展開の選択に役立ちます。

この結果は、Ensembleが大規模なメッセージング要件を、極めて小規模なハードウェア（コモディティ）上でサポート可能なことを示しています。小さな単一サーバで、HL7メッセージングを全組織でサポートする事も可能です。

Ensembleアクティビティの異なる面を示すために、以下の3つのワークロードを課しました。

• T1 ワークロード：単純なHL7メッセージの流れ（各インバウンドメッセージに対し１つのアウトバウンドメッセージ）。これらのメッセージは、ルーティングエンジンを使用せずに、EnsembleのビジネスサービスからEnsembleのビジネスオペレーションに、直接渡される。ルーティングルールは使用せず、変換も行われない。1インバウンドメッセージにつき、1つのHL7メッセージのインスタンスがデータベースに生成される。
• T2 ワークロード：ルーティグエンジンを使用して、インバウンドメッセージの平均4セグメントを変更し、１つのアウトバンドインターフェースにルートさせる（１回の変換を含む１対１）。それぞれのインバウンドメッセージに対し、データ変換が1回行われ、2つのHL7メッセージオブジェクトがデータベース内に生成される。
• T4 ワークロード ： ルーティングエンジンを使って、別々の変更メッセージを、各4つのアウトバウンドインターフェースにルートさせる。平均では、インバウンドメッセージの4セグメントは、各変換において変更される（４回の変換を含む１対４）。各インバウンドメッセージに対し、データ変換が4回行われ、4つのメッセージがアウトバウンドに送信される。5つのHL7メッセージオブジェクトがデータベース内に生成される。

この3つのワークロードは、6コア、12コアで行われました。データは、毎秒（毎時）のインバウンド数、毎秒（毎時）のアウトバウンド数、1日（10時間）の合計メッセージ数（インバウンドとアウトバウンドの合計）を表しています。CPU利用率は、与えられたスループットにおける利用可能なシステムリソースを示します。また、全ての場合で、16のインバウンドと16のアウトバウンドインターフェースが使用されました。

6コアでの拡張性

表2は、6コア構成での一番良い結果をまとめています。

表2: 6コアにおけるEnsemble 2010.2 HLv2の拡張性

12コアでの拡張性

表3は、12コア構成における3つの各ワークロードについて最も良い結果をまとめています。

表3: 12コアでのEnsemble 2010.2 HL7v2 の拡張性

最後に、グラフ1では、コアの数が6から12に倍増した時、どのタイプのテストでもEnsembleは、ほぼリニアに拡張可能なことを示しています。

グラフ 1: 6コア､12コア構成におけるEnsemble 2010.2 の拡張性のテスト結果

テストされたワークロードは、HL7v2の患者管理（ADT）と観察報告(ORU)メッセージを含み、それらの平均は、サイズで1.2KB､セグメントで14でした。約4セグメントは変換により変更が加えられました（T2、T4ワークロード）。これらのテストは、16のインバウンドと16のアウトバウンドインターフェースが、TCP/IP上でメッセージの送受信を行っていることを示しています。拡張性は、各インターフェースのトラフィックを少しずつ増加させることで測定しました。インターフェースの数を変化させるテストでは、全体的なスループット、またはパフォーマンスには殆ど差は出ませんでした。それが、16のインバウンドと16のアウトバウンドインターフェースがこれらのテストで使用された理由です。

許容テストでは、最小のキューで安定した状態が維持可能であることを実証しています。キューイングはメッセージのサービスの質が低いことを意味し、メッセージの処理と、配信先のシステム（複数のシステム）へのメッセージ配信に遅延が生じる可能性があります。テスト方法では、１つのメッセージで1秒以上遅延する可能性のあるキューイングがあるテストは除外しました。さらに、CPU使用率が75％以上だったテストも除外しました。この文書にある結果報告では、実験的なテストと実稼働システムの差異を考慮して、ベンチマークディスカウント（20%）― ベンチマークにおける測定結果を20%割り引く― を含んでいます。

以前行われたテストでは、HL7メッセージのタイプはEnsemble のパフォーマンスと拡張性に関しては、大きな影響を与えませんでした。大きな点は、インバウンドメッセージの数と、インバウンド、アウトバウンドメッセージのサイズ、ルーティングエンジンで生成される新しいメッセージの数、変更されたセグメントの数でした。

さらに、以前のテストでは、データ変換においてHL7メッセージの個別のフィールド処理は、通常パフォーマンスに影響を与えません。これらのテストで変換を行う際は、新しいメッセージ生成に、非常に簡単なアサイメントを使用しました。従って（データ変換においてリソース集中型のSQLクエリを使用するような）複雑な処理を行う際は、結果が変化する可能性があります。

以前のテストでは、通常、ルール処理は影響がないことを実証しました。これらのテストで使用されたルーティングルールの組み合わせは、平均32ルールで、全てシンプルなものでした。「全てのルールを実行する」ことは誤った処理とされ、ルールセットにおける全てのルールは、同等に扱われました。従って、極端に大きい、または複雑なルールは結果が変化する可能性があります。

このテストでは、32GB RAMのデュアルのヘクサコアIntel Xeon X5670 “Westmere” プロセッサ（12コアで2.93GHz、2 チップ、 1チップ当たり6 コア、 1コア当たり2 スレッド）を使用しました。OSはRed Hat Enterprise Linux サーバ 5.5 (Tikanga) です。

これらのテストでは、ハイパースレッディング（HT）テクノロジを使用しました。一連のテストが行われ、Ensemble のパフォーマンスに与えるHTの影響を検証しました。結論として、Intel Xeon 5670 (Westmere)プロセッサ上でのHTは、ワークロードを完了するのにかかる時間を減らすことで、パフォーマンスに、そのままプラスの影響があることが分かりました。他のアーキテクチャやチップ上のHTは、パフォーマンスにマイナス（もしくは、どちらでもない）の影響を与える可能性があり、HTを有効にする前に、これらのプラットフォームのパフォーマンス評価を行う配慮が必要です。さらにこのテストでは、比較的小さいディスク構成を使用し、データベースファイル、ジャーナルファイル、ライトイメージジャーナル（WIJ）は、シンプルにするために、全て一つの内部ディスク上に構成されました（プロダクションシステムの場合は推奨しません）。

InterSystems Caché® 、Ensembleについて、標準的なインターシステムズのプラットフォームの特定構成とチューニングガイドラインに加え 、以下のガイドラインが該当します。

CPU構成

SPEC （Standard Performance Evaluation Corporation）は、ベンチマークの標準化を推進する団体で、プラットフォームに渡る構成のベースラインを提供しています。SPECベンチマークのコンポーネントの一つは、CINT2006で、これは特定のCPUの整数処理のパフォーマンスをテストします。SPECは、ベンチマークプログラムの基本ランタイムを定めており、リファレンスタイムとして知られています。時間計測テストは様々なテストシステム上で実行され、この値はリファレンスタイムと比較され、比率が算出されます。このテストの比率は、SPECint2006 スコア（またはCINT2006スコア）と呼ばれています。SPECintスコアは、通常クロスプラットフォームの構成を比較するのに使われます。

インターシステムズがテストしたシステムは、２ヘクサコアの Intel Xeon X5670 プロセッサ (2.93 GHz)で構成されていました。このプロセッサは、CINT2006 ベースラインスコアでは36.6でした。従って、12コア構成では、439.2 (36.6 x 12)の、ベースラインスコアとなります。これらの値は、他のプラットフォームと比較し、Intel Xeon X5670プラットフォーム上で達成可能なレベルを維持するのに必要なPCの能力を決定するガイドラインとして使用できます。

例えば、Intel Xeon X5550 (2.66 GHz)のCINT2006 ベースラインスコアは29.7です。これは、テストを行ったIntel Xeon X5670より、スループットが約19%低い(29.7/36.6)　ことを示しています。従って、Intel Xeon X5670プロセッサの代わりに、Intel Xeon X5550プロセッサで同程度のシステムを構成する場合、Ensemble のメッセージ処理は、約19% 少ないことが予想されます。

ディスク構成

前述のように、Ensembleを流れるメッセージは、完全にディスクに永続化されます。この文書で既に述べたT4のワークロードで、インバウンドのHL7の各メッセージは、約50KBのデータを生成します。この数値は、以下の表のように分けることができます。

表 4: インバウンドのHL4 T4メッセージに関するディスク要件.

T4ワークロードは、ルーティングエンジンを使用して、４つのアウトバウンドインターフェースに、別々に変更されたメッセージを送信したことは既に述べました。インバウンドメッセージの平均４セグメントは、それぞれの変換で変更されました（４回の変換を含む　1対4）。各インバウンドメッセージでは、4回のデータ変換が行われ、4つのメッセージがアウトバウンドに送信されました。また、5つのHL7メッセージオブジェクトがデータベース内に生成されました。

プロダクション利用のためのシステムを構成する場合、その要件は日々のインバウンドの量だけでなく、HL7メッセージのパージスケジュールを考慮して計算する必要があります。さらに、ジャーナルが一杯になるのを防ぐために、システム上に適切なジャーナルファイルのスペースを設定する必要があります。ジャーナルファイルは、パフォーマンスと信頼性を考慮し、データベースファイルから物理的に別のディスクに記録すべきです。