パフォーマンスプランニング
Windchill ESI をインストールする前に、システムパフォーマンスプランニングに関する要因についても検討する必要があります。このセクションでは、Windchill ESI のパフォーマンスを検討する際に注意して確認すべき重要な領域について説明します。
それぞれの環境は一意で、システム統合プロジェクトは本質的に複雑なので、すべてのシステムのパフォーマンスを同じ手順で最適化することはできません。しかし、熟練したシステムインテグレーターの経験に基づいた以下の情報は、特定のパフォーマンスの目標を達成するために役立ちます。内容は次のとおりです。
• メッセージの数とサイズの分析
• 潜在的なパフォーマンスボトルネックの特定
• ESI のパフォーマンスに関連する設計概念の理解
• パフォーマンス調整パラメータおよび調整方法の適用
メッセージの数とサイズの分析
パフォーマンスを最適化する場合、統合する TIBCO コンポーネントとシステム間のインタフェースにおける、パブリッシング操作の各トランザクションで生じるデータロードを特定して数値化すると有益です。以下の領域で、メッセージの数とサイズを検討します。
JMS インタフェース
JMS インタフェースについて、インタフェースでのトランザクションごとのメッセージの数の合計を以下に示します。
• ESIResponse (1)
• ESIPostResult = ESIResponse のビジネスオブジェクトまたはサブトランザクションの数 + 1 (n+1)
• ESIResultReponse (n+1)
一般的に、レスポンスメッセージには、トランザクションのすべての製品構造データが含まれているので、そのサイズはほかのメッセージよりも非常に大きくなります。
Rendezvous インタフェース
Rendezvous インタフェースの場合、各トランザクションのメッセージ数は以下のメッセージ数の合計になります。
• ビジネスオブジェクトまたはサブトランザクションごとの API 呼び出し (約 3) を ESIResponse メッセージのビジネスオブジェクトまたはサブトランザクションの数で乗算した数
• ERP API 結果 (約 3) を ESIResponse メッセージのビジネスオブジェクトまたはサブトランザクションの数で乗算した数
通常、各 API メッセージは単一のビジネスオブジェクトの属性データを含み、そのサイズは非常に小さくなります。
|
|
Windchill ESI サービスにより、リリース内の ERP インスタンスと同じ数のトランザクションが生成されます。したがって、リリース (つまりパブリッシング操作) ごとのメッセージの数は、トランザクションごとのメッセージの数を、そのリリースで生成されたトランザクションの数で乗算した数に等しくなります。
|
潜在的なパフォーマンスボトルネックの特定
パフォーマンスを計画する際、以下のような潜在的なボトルネックの原因を特定することも重要です。
• エンドシステムを統合する際に発生する遅延の影響と時間差。以下の項目が含まれます。
◦ Windchill PDMLink が複合 XML データレスポンスメッセージで応答するために要する時間。
◦ バッチデータ転送に対する SAP システムへの複数のオブジェクト指向 API 呼び出しの影響
◦ TIBCO アダプタと SAP インタフェース間の遅延
• アダプタインスタンスと SAP 間の処理時間。複雑で多層化した SAP アーキテクチャと低レベルの RFC 通信が必要になるため、一般にアダプタインスタンスと SAP との間の処理は、BusinessWorks プロセスからアダプタへの比較的単純なマッピングに必要なリソースを超過します。
リソースの消費とタイミングを分析するには、TIBCO BusinessWorks Administrator のパフォーマンス監視機能を使用します。詳細については、TIBCO Administrator Users Guide を参照してください。
Windchill ESI のパフォーマンス関連の設計概念
このセクションでは、パフォーマンスに影響を与える可能性のある Windchill ESI の設計について説明します。これらの概念を考慮することは、最適なパフォーマンスを評価して計画するうえで有益です。
• Windchill ESI では TIBCO Rendezvous Certified Messaging (RVCM) を使用しないので、元帳ファイルの管理がパフォーマンスに影響を与えません。Windchill ESI では JMS、要求/応答メッセージ、および同期 SAP API を戦略的に使用することから、Reliable Messaging (RV) 配布オプションには堅牢なトランザクション管理サービスがあります。
• Windchill ESI は、TIBCO BusinessWorks 処理フローの重要なポイントでチェックポイントを使用して、システム障害時のデータ破損を防止します。チェックポイントは、アプリケーションの現在の状態をディスクに保持するので、メモリベースの操作よりも実行速度が著しく低下します。しかし、チェックポイントの場所は、パフォーマンスに与える影響を最小限に抑えながら、堅牢なトランザクションの整合性を維持するように計画的に設計されています。
• Windchill ESI は、外部またはサードパーティデータベースを使用しないので、それらに関連するパフォーマンスの影響を受けません。
• Windchill ESI は、単一の製品データリリース操作 (単一の BusinessWorks ジョブ内) でマルチスレッド (並列処理) をサポートしません。これは、SAP によって要求されるオブジェクト処理シーケンスが原因です。マルチスレッド/並列処理は異なるジョブ間でサポートされます。
• Windchill ESI は、デフォルトではすべての SAP オブジェクトについて単一のアダプタ設定を使用します。言い換えると、アダプタインスタンスは TIBCO の自動ロードバランス (RVCMQ) 機能を使用しません。これは、設定された SAP API の複雑さ (単一のビジネスオブジェクトを処理するために複数の API 呼び出しが必要) と TIBCO によるアダプタセッションの管理制約に起因します。アダプタの処理能力が重要な関心事であれば、後述するパフォーマンス調整オプションを参照するか、1 回の API 呼び出しでビジネスオブジェクトを処理できる新しい SAP API を開発してください。新しい SAP API の開発は RVCMQ 機能を使用するオプションの再構築に役立ちますが、Windchill ESI アプリケーションを大幅にカスタマイズする必要があります。
パフォーマンス調整パラメータおよび調整方法の適用
このセクションでは、システムパフォーマンスを調整して向上するための方法を説明します。まず、パフォーマンス調整方法を適用できる領域を示し、次に推奨されているパフォーマンス調整方法を示します。
調整するコンポーネント
最適なパフォーマンスとスケーラビリティを実現するために、以下のコンポーネントと領域を調整できます。
• TIBCO BusinessWorks アプリケーション: このコンポーネントは、Java 仮想マシン (JVM) を作成する埋め込み実装の Java Runtime Environment (JRE) を使用します。JVM を調整してパフォーマンスを向上させることができます。
• TIBCO BusinessWorks プロセスエンジン: ジョブの論理グループです。プロセスエンジンは、単一の Java 仮想マシン (JVM) 内で実行します。
• TIBCO BusinessWorks ジョブ: BusinessWorks プロセステンプレートのインスタンスで、リソースを消費します。1 つのジョブは、ERP インスタンスごとの 1 回の Windchill ESI の製品データパブリッシング操作全体、つまり 1 回の ESI トランザクションに相当します。
• TIBCO BusinessWorks スレッド: Java のスレッドと同じです。スレッドは、ジョブのワーカーのプールを表します。各スレッドは、一定数の BusinessWorks アクティビティを実行した後、プールに解放されます。
• アダプタ接続: 配布ターゲットで使用できるデータチャネルを表します。接続する方法と接続を解放するタイミングの詳細については、該当する TIBCO アダプタのドキュメンテーションを参照してください。
• JVM メモリサイズ: JVM メモリサイズを監視して、指定した数のジョブで消費されるメモリの量を確認し、使用可能なメモリの上限に達していないかどうかをチェックする必要があります。この機能は、基本的なオペレーティングシステムツールを使用して実行できます。
• CPU 使用率の割り当て: 複数の CPU が使用可能な場合でも、アプリケーションリソースロードが各 CPU に自動的に分散されるわけではないので、このアクティビティを監視する必要があります。通常、CPU のロードバランスは、オペレーティングシステムレベルで設定されます。
• 追加されたホストマシン :物理サーバーを追加すると、データの処理能力とともに、機能の可用性も向上します。
パフォーマンス調整方法
パフォーマンスとスケーラビィティを向上させるために使用する調整方法を以下に示します。
• データボリューム/周波数を分析して、アダプタのメモリ消費量を予測します。ベースラインを確立するために、使用していないアダプタインスタンスのメモリ消費を測定します。
• 環境における遅延を評価します。この遅延は、エンドシステムを統合する際に重要です。
• BusinessWorks で使用されていないプロセスエンジンジョブの数を最小にします。これらのプロセスエンジンジョブは、必要以上にメモリを消費します。
• 以下の推奨事項を使用して Java 仮想マシン (JVM) を調整するオプションを検討します。
◦ 使用するオペレーティングシステムの最新の JVM パッチを適用します。
◦ ヒープおよびスタックのサイズを調整して、ガベージコレクションを最適化します。これには、TIBCO BusinessWorks エンジンのスレッドスタックサイズ展開設定の最適値の選択も含まれます。
◦ アプリケーションの特性に合わせてオペレーティングシステムのカーネルパラメータを調整します。
◦ JVM の -Xms および -Xmx パラメータを設定します。これらのパラメータは、オペレーティングシステムに依存せず、起動時に JVM に割り当てられるメモリの量 (-Xms) および JVM が消費できる最大メモリ量 (-Xmx) を制御します。どちらのパラメータも 512 MB 以上に設定する必要があります。テストまたは運用時にアプリケーションが java.lang.OutOfMemoryErrors を生成する場合、-Xmx パラメータの値を大きくする必要があります。
◦ その他の JVM パラメータと調整オプションを確認します。JVM とオペレーティングシステムによっては、その他の調整オプションを使用できる場合があります。以下の Web サイトを参照してください。
▪ http://www.javaperformancetuning.com/tips/rawtips.shtml
▪ http://java.sun.com/docs/hotspot/VMOptions.html
◦ 最新バージョンの JRE を確認します。JRE のバージョンを最新にするとパフォーマンスが向上する場合があります。ただし、そのバージョンがサポート対象であることを確認してください。
|
|
TIBCO は自動的に EMS 上に送信される XML データを最大 90% 圧縮します。
|
