2 ネットワーク・パフォーマンス・テストの実行

この章では、複数のコンピュータ間のネットワーク・パフォーマンスをテストする手順について説明します。データグラム・ユーティリティおよびメッセージ・バス・ユーティリティという2つのユーティリティが用意されています。本番デプロイメントの前に、両方のテストの実行に成功する必要があります。

この章の内容は次のとおりです。

親トピック: 基本的な管理

2.1 データグラム・テスト・ユーティリティの使用

Coherenceデータグラム・テスト・ユーティリティは、複数のコンピュータ間のネットワーク・パフォーマンスをテストしてチューニングするために使用します。このユーティリティにより、Coherenceクラスタ管理通信に対応するようネットワークが最適に構成されます。テストには次の2種類があります。サーバーのペアのパフォーマンスをテストすることにより、それらが正しく構成されているかどうかを確認するポイント・ツー・ポイント・テストと、ネットワーク自体が正しく機能しているかどうかを確認する分散データグラム・テストです。どちらのテストの実行にも成功する必要があります。

データグラム・テストは、3種類のモード(パケット・パブリッシャまたはパケット・リスナー、あるいはその両方)のいずれかで動作します。このユーティリティを実行すると、パブリッシャがパケットをリスナーに送信し、そのリスナーがスループットや成功率などの統計を測定します。このテストの結果に基づいて環境をチューニングして、最大のパフォーマンスを実現します。パフォーマンス・チューニングを参照してください。

この項には次のトピックが含まれます:

2.1.1 データグラム・テスト・ユーティリティの実行

データグラム・テスト・ユーティリティを実行するには、コマンド行からcom.tangosol.net.DatagramTestクラスを使用するか、COHERENCE_HOME/binディレクトリにあるdatagram-testスクリプトを実行します。スクリプトは、WindowsベースのプラットフォームとUNIXベースのプラットフォームの両方に用意されています。

次の例は、DatagramTestクラスの使用方法を示しています。

java -server -cp coherence.jar com.tangosol.net.DatagramTest <command value> <command value> ...

次の例は、スクリプトの使用方法を示しています。

datagram-test <command value> <command value> ...

表2-1では、データグラム・テスト・ユーティリティで利用できるコマンド行オプションについて説明しています。

表2-1 データグラム・テスト・ユーティリティのコマンド行オプション

コマンド	必須/オプション	適用範囲	説明	デフォルト値
-local	オプション	両方	バインド先のローカル・アドレス、`addr:port`の形式で指定	localhost:9999
-packetSize	オプション	両方	作業対象パケットのサイズ、バイト単位で指定	1468
-payload	オプション	両方	各パケットに含めるデータ量パケット・サイズを一致させるには、`0`を使用	0
-processBytes	オプション	両方	処理対象の各パケットのバイト数(4の倍数)	4
-rxBufferSize	オプション	リスナー	受信バッファのサイズ、パケット単位で指定	1428
-rxTimeoutMs	オプション	リスナー	接続が閉じられるまでの非アクティブ時間	1000
-txBufferSize	オプション	パブリッシャ	送信バッファのサイズ、パケット単位で指定	16
-txRate	オプション	パブリッシャ	データ送信の速度、メガバイト単位で指定	unlimited
-txIterations	オプション	パブリッシャ	終了前に公開するパケット数を指定	unlimited
-txDurationMs	オプション	パブリッシャ	終了前に公開する期間を指定	unlimited
-reportInterval	オプション	両方	レポートを出力する間隔、パケット単位で指定	100000
-tickInterval	オプション	両方	ティック・マークを出力する間隔	1000
-log	オプション	リスナー	測定したパフォーマンスの表形式レポートを保存するファイルの名前	なし
-logInterval	オプション	リスナー	ログに測定結果を出力する間隔	100000
-polite	オプション	パブリッシャ	パブリッシャが公開を実行する前に、リスナーの接続を待つかどうかを示すスイッチ	off
-provider	オプション	両方	使用するソケット・プロバイダ(`system`、`tcp`、`ssl`、`file`:`xxx.xml`)	system
引数	オプション	パブリッシャ	空白で区切られた公開先アドレスのリスト、`addr:port`の形式で指定	なし

2.1.2 データグラム・ネットワーク・パフォーマンスのテスト方法

この項には、ポイント・ツー・ポイント・データグラム・テストと分散データグラム・テストを実行するための手順が含まれます。どちらのテストの実行にも成功する必要があり、その際に重大なパフォーマンスの問題やパケットの損失が発生していないことも示す必要があります。データグラム・レポート統計の理解を参照してください。

この項には次のトピックが含まれます:

2.1.2.1 ポイント・ツー・ポイント・データグラム・テストの実行

この項の例では、サーバーA (IPアドレス195.0.0.1)と、サーバーB (IPアドレス195.0.0.2)という2つのサーバー間のネットワーク・パフォーマンスのテスト方法を示します。一方のサーバーはパケット・パブリッシャとして動作し、もう一方はパケット・リスナーとして動作します。パブリッシャは可能なかぎり高速にパケットを送信し、リスナーはパフォーマンス統計を測定して報告します。

まず、サーバーA上のリスナーを起動します。次に例を示します。

datagram-test.sh

[ENTER]を押すと、ユーティリティは、パケット受信の準備が完了していることを示します。例2-1にサンプル出力を示します。

例2-1 リスナーの起動からの出力

starting listener: at /195.0.0.1:9999
packet size: 1468 bytes
buffer size: 1428 packets
  report on: 100000 packets, 139 MBs
    process: 4 bytes/packet
        log: null
     log on: 139 MBs

デフォルトでは、このテストにより、1428個のパケット(約2MB)を十分に保持できるネットワーク受信バッファの割当てが試行されます。このバッファの割当てができない場合、ユーティリティはエラーを報告して終了します。-rxBufferSizeパラメータを使用して要求するバッファのサイズを小さくするか、オペレーティング・システムのネットワーク・バッファの設定を大きくしてください。オペレーティング・システムのバッファを大きくすると、最適なパフォーマンスが得られます。本番チェックリストを参照してください。

サーバーBでパブリッシャを起動して、サーバーAに向けてパブリッシュします。次に例を示します。

datagram-test.sh servera

[ENTER]を押すと、Server Bのテスト・インスタンスによってリスナーとパブリッシャの両方が起動されます。ただし、この構成ではリスナーは使用しません。例2-2は、Server Bのコマンド・ウィンドウに表示されるサンプル出力を示しています。

例2-2 データグラム・テスト: サーバーでのリスナーとパブリッシャの起動

starting listener: at /195.0.0.2:9999
packet size: 1468 bytes
buffer size: 1428 packets
  report on: 100000 packets, 139 MBs
    process: 4 bytes/packet
        log: null
     log on: 139 MBs

starting publisher: at /195.0.0.2:9999 sending to servera/195.0.0.1:9999
packet size: 1468 bytes
buffer size: 16 packets
  report on: 100000 packets, 139 MBs
    process: 4 bytes/packet
      peers: 1
       rate: no limit

no packet burst limit
oooooooooOoooooooooOoooooooooOoooooooooOoooooooooOoooooooooOoooooooooOoooooooooO

データがネットワーク上に出力(Output)されると、一連のoとOのマークが表示されます。oはそれぞれ1000パケットを表し、10,000パケットごとにOのインジケータが表示されます。

サーバーAでは、これに対応してネットワーク入力(Input)を表すiとIのマークのセットが表示されます。これは、2つのテスト・インスタンスが通信していることを示します。

2.1.2.2 双方向データグラム・テストの実行

ポイント・ツー・ポイント・テストは、双方向モードで実行することもできます。このモードでは、サーバーがパブリッシャとリスナーとして動作します。ポイント・ツー・ポイント・テストで使用したのと同じテスト・インスタンスを使用して、サーバーAのインスタンスにサーバーBのアドレスを指定します。たとえば、サーバーAで次のコマンドを実行します。

datagram-test.sh -polite serverb

-politeパラメータを使用して、このテスト・インスタンスに対し、データの受信を開始するまでパブリッシュを開始しないように指示します。前述の同じコマンドをサーバーBで実行します。

datagram-test.sh servera

2.1.2.3 分散データグラム・テストの実行

分散テストは、3台以上のコンピュータのパフォーマンスをテストするために使用します。たとえば、1つのリスナーをターゲットにするように、2つのパブリッシャを設定できます。このスタイルのテストは単純な1対1のテストと比較してはるかに現実的で、他の方法では確認できないネットワークのボトルネックを特定できる場合があります。

次の例では、4台のコンピュータ間でダイアグラム・テストを実行します。

サーバーA上:

datagramtest.sh -txRate 100 -polite serverb serverc serverd

サーバーB上:

datagramtest.sh -txRate 100 -polite servera serverc serverd

Server C上:

datagramtest.sh -txRate 100 -polite servera serverb serverd

サーバーD上:

datagramtest.sh -txRate 100 servera serverb serverc

このテスト・シーケンスでは、すべてのノードは他のすべてのノードに、1秒当たりで合計100MBを送信します(1ノード当たり33MB/秒に相当)。完全にスイッチが設定された1GbEネットワークでは、パケットを失うことなくこれを達成できる必要があります。

テストの実行を簡略化するために、すべてのノードは同一のターゲット・リストを使用して起動できます。自分自身への送信も行われますが、このループバック・データは容易に除外できます。最後のノードが起動されるまで他のすべてのノードが遅延するため、最後のノードを除くすべてのノードは、-politeスイッチを使用して起動することが重要です。

2.1.3 データグラム・レポート統計の理解

テストのそれぞれの側(パブリッシャとリスナー)から定期的にパフォーマンス統計がレポートされます。パブリッシャでは、ネットワーク上にデータを公開する速度のみがレポートされます。次に例を示します。

Tx summary 1 peers:
   life: 97 MB/sec, 69642 packets/sec
    now: 98 MB/sec, 69735 packets/sec

このレポートには、現在の送信速度(前回のレポート以降)と存続期間の送信速度の両方が記載されます。

表2-2は、リスナーでレポートできる統計について説明しています。

表2-2 リスナーの統計

項目	説明
Elapsed	レポート対象の時間間隔
Packet size	受信したパケットのサイズ
Throughput	パケットの受信速度
Received	受信したパケット数
Missing	失われていることが検出されたパケットの数
Success rate	合計送信パケット数に対する受信パケット数の割合
Out of order	着信順序が乱れているパケットの数
Average offset	パケットの着信順序の乱れの程度を示すインジケータ

パブリッシャの場合と同様、現在と存続期間の両方の統計がレポートされます。次の例は、一般的なリスナーのレポートを示しています。

Lifetime:
Rx from publisher: /195.0.0.2:9999
             elapsed: 8770ms
         packet size: 1468
          throughput: 96 MB/sec
                      68415 packets/sec
            received: 600000 of 611400
             missing: 11400
        success rate: 0.9813543
        out of order: 2
          avg offset: 1


Now:
Rx from publisher: /195.0.0.2:9999
             elapsed: 1431ms
         packet size: 1468
          throughput: 98 MB/sec
                      69881 packets/sec
            received: 100000 of 100000
             missing: 0
        success rate: 1.0
        out of order: 0
          avg offset: 0

特に重要な項目は、throughputとsuccess rateです。目標は、success rateを可能なかぎり1.0近くに維持しながら、最高のthroughputを見つけることです。100Mbネットワークの設定では、約10MB/秒の速度を達成する必要があります。1Gbネットワークの設定では、約100MB/秒の速度を達成する必要があります。これらの速度を実現するには、なんらかの速度調整が必要になります。ネットワークがこれらの速度を達成できない場合、または速度がかなり低い場合、ネットワーク構成の問題がある可能性が非常に高いです。ネットワークのチューニングを参照してください。

速度調整

-txRate Mパラメータを組み込むことによって、テストのパブリッシャ側で、MB/秒単位のデータ速度を指定して速度を調整できます。Mは、テストでネットワークに設定される最大MB/秒を表します。

2.2 メッセージ・バス・テスト・ユーティリティの使用

Coherenceメッセージ・バス・テスト・ユーティリティは、メッセージ・バスの実装のパフォーマンス特性とそれらが動作するネットワークのテストに使用します。このユーティリティにより、クラスタ・データ・サービス間の通信に対応するようネットワークが最適に構成されます。具体的には、このユーティリティを使用して、Exalogic以外のシステムに対するデフォルト・トランスポートであるTCPメッセージ・バス(TMB)の実装と、Exalogicシステムに対するデフォルト・トランスポートであるインフィニバンド・メッセージ・バス(IMB)の実装をテストできます。このテストの結果に基づいて環境をチューニングすることで、最大のパフォーマンスを実現します。TCPに関する考慮事項を参照してください。

この項には次のトピックが含まれます:

2.2.1 メッセージ・バス・テスト・ユーティリティの実行

メッセージ・バス・テスト・ユーティリティを実行するには、コマンドラインからcom.oracle.common.net.exabus.util.MessageBusTestクラスを使用します。次の例は、MessageBusTestクラスの使用方法を示しています。

java -server -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest <command value> <command value> ...

表2-3では、メッセージ・バス・テスト・ユーティリティで使用できるコマンドライン・オプションについて説明しています。

表2-3 メッセージ・バス・テスト・ユーティリティのコマンドライン・オプション

コマンド	必須/オプション	説明	デフォルト値
-bind	必須	作成する1つ以上のローカル・エンド・ポイントのリスト	なし
-peer	必須	送信先となる1つ以上のリモート・エンド・ポイントのリスト	なし
-rxThreads	オプション	バウンド・エンドポイント(リエントラント不可)ごとの受信スレッド数
-txThreads	オプション	バウンド・エンドポイントごとの送信スレッド数
-msgSize	オプション	送信するメッセージ・サイズの範囲で、`min[..max]`形式で指定します。	4096
-chunkSize	オプション	1単位として処理するバイト数を定義します。つまり、byteの場合は1、longの場合は8で、0 (ゼロ)を指定すると無効になります
-cached	オプション	可能であればメッセージ・オブジェクトを再利用して、バッファ・マネージャのオーバーヘッドを軽減します
-txRate	オプション	ターゲットのアウトバウンド・データ率(Mbps)
-txMaxBacklog	オプション	テストで送信スレッドごとに生成される最大バックログ。
-rxRate	オプション	ターゲットのインバウンド・データ率(Mbps)`-rxThreads`が0 (ゼロ)以下の場合、使用できません。
-flushFreq	オプション	フラッシュ前に送信するメッセージ数、または自動の場合は0	0
-latencyFreq	オプション	待機時間のサンプリングまでに送信するメッセージ数	100
-noReceipts	オプション	指定した場合は受信を使用せず、GCにメッセージの再利用を任せます	false
-manager	オプション	使用するバッファ・マネージャ(net、directまたはheap)	net
-depotFactory	オプション	`Depot`インスタンスの取得に使用するファクトリ・クラスの完全修飾名
-reportInterval	オプション	レポートの間隔	5秒
-polite	オプション	指定した場合、このインスタンスは接続するまで送信を開始しません
-block	オプション	指定した場合、レスポンスの待機中、送信スレッドでブロックされます	false
-relay	オプション	指定した場合、受信されたメッセージはピアの1つにリレーされます	false
-ignoreFlowControl	オプション	指定した場合、フロー・コントロール・イベントは無視されます。フロー・コントロール・イベントを無視する場合は、`-txMaxBacklog`コマンドを使用してメモリー不足エラーを防ぎます	false
-poll	オプション	指定した場合、`PollingEventCollector`の実装が使用され、イベントをすべてキューに入れて適合する場合のみ返します。通常、ポーリング・コレクタには、`-rxThreads`コマンドを1に設定する必要があります。
-prompt	オプション	指定した場合、各送信前にユーザーにプロンプトが表示されます
-tabular	オプション	指定した場合、出力に表形式が使用されます
-warmup	オプション	ウォームアップのために廃棄される期間またはメッセージ数	0
-verbose	オプション	指定した場合、詳細デバッグ出力が可能になります

2.2.2 メッセージ・バス・パフォーマンスのテスト方法

この項では、TMBトランスポートに対するポイント・ツー・ポイント・メッセージ・バス・テストおよび分散メッセージ・バス・テストの実行手順を説明します。どちらのテストの実行にも成功する必要があり、その際に重大なパフォーマンスの問題やエラーが発生していないことも示す必要があります。

この項には次のトピックが含まれます:

2.2.2.1 ポイント・ツー・ポイント・メッセージ・バス・テストの実行

この項の例では、サーバーA (IPアドレス195.0.0.1)と、サーバーB (IPアドレス195.0.0.2)という2つのサーバー間のネットワーク・パフォーマンスのテスト方法を示します。サーバーAはサーバーとして動作し、サーバーBはクライアントとして動作します。

まず、サーバーA上のリスナーを起動します。次に例を示します。

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://servera:8000

[ENTER]を押すと、ユーティリティは、メッセージ受信の準備が完了していることを示します。例2-3にサンプル出力を示します。

例2-3 サーバー・リスナーの起動からの出力

OPEN event for tmb://195.0.0.1:8000

サーバーBでクライアントを起動し、サーバーAにメッセージを送信させます。次に例を示します。

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverb:8000 -peer tmb://servera:8000

サーバーBのテスト・インスタンスによってクライアントとサーバー・リスナーの両方が起動されます。メッセージ・バス・テストは、常に双方向通信を実行します。デフォルト・モードでは、クライアントはサーバーにメッセージを絶え間なく送信し、サーバーは定期的にクライアントに応答します。この構成では、通信の大部分がクライアントからサーバーへのものであるのに対し、サーバーからクライアントへの通信は頻度が低いので待機時間の測定を考慮に入れます。例2-4は、Server Bのコマンド・ウィンドウに表示されるサンプル出力を示しています。

注意:

例2-4のパフォーマンス結果は、ご使用のネットワーク環境を示していない可能性もあります。

例2-4 メッセージ・バス・テスト — クライアントおよびサーバーの起動

OPEN event for tmb://195.0.0.2:8001
CONNECT event for tmb://195.0.0.1:8000 on tmb://195.0.0.2:8001
now:  throughput(out 65426msg/s 2.14gb/s, in 654msg/s 21.4mb/s),
   latency(response(avg 810.71us, effective 1.40ms, min 37 .89us, max 19.59ms),
   receipt 809.61us), backlog(out 42% 1556/s 48KB, in 0% 0/s 0B), connections 1,
   errors 0
life: throughput(out 59431msg/s 1.94gb/s, in 594msg/s 19.4mb/s),
   latency(response(avg 2.12ms, effective 3.85ms, min 36.32us, max 457.25ms),
   receipt 2.12ms), backlog(out 45% 1497/s 449KB, in 0% 0/s 0B), connections 1,
   errors 0

デフォルトのテストでは、最大帯域幅を使用して最大量のメッセージのプッシュを試行しますが、待機時間が長くなります。-blockコマンドを使用し、データのストリーミングをリクエストとレスポンスで切り替えてテストすると、ネットワークの最小待機時間の改善が示されます。

now:  throughput(out 17819msg/s 583mb/s, in 17820msg/s 583mb/s),
   latency(response(avg 51.06us, effective 51.06us, min 43.42us, max 143.68us),
   receipt 53.36us), backlog(out 0% 0/s 0B, in 0% 0/s 0B), connections 1, errors 0
life: throughput(out 16635msg/s 545mb/s, in 16635msg/s 545mb/s),
   latency(response(avg 56.49us, effective 56.49us, min 43.03us, max 13.91ms),
   receipt 59.43us), backlog(out 0% 0/s 2.18KB, in 0% 0/s 744B), connections 1,
   errors 0

2.2.2.2 双方向メッセージ・バス・テストの実行

ポイント・ツー・ポイント・テストは、双方向モードで実行することもできます。このモードでは、サーバーがクライアントとサーバーの両方として動作します。ポイント・ツー・ポイント・テストで使用したのと同じテスト・インスタンスを使用します。たとえば、サーバーAで次のコマンドを実行します。

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://servera:8000 -peer tmb://serverb:8000 -polite

-politeパラメータを使用して、このテスト・インスタンスに対し、データの受信を開始するまでパブリッシュを開始しないように指示します。サーバーBで次を実行します。

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverb:8000 -peer tmb://servera:8000

2.2.2.3 分散メッセージ・バス・テストの実行

分散テストは、3台以上のコンピュータのパフォーマンスをテストするために使用します。このスタイルのテストは単純な1対1のテストと比較してはるかに現実的で、他の方法では確認できないネットワークのボトルネックを特定できる場合があります。

次の例では、4台のコンピュータ間で双方向メッセージ・バス・テストを実行します。

サーバーA上:

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://servera:8000 -peer tmb://serverb:8000 tmb://serverc:8000 tmb://serverd:8000 -polite

サーバーB上:

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverb:8000 -peer tmb://servera:8000 tmb://serverc:8000 tmb://serverd:8000 -polite

Server C上:

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverc:8000 -peer tmb://servera:8000 tmb://serverb:8000 tmb://serverd:8000 -polite

サーバーD上:

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverd:8000 -peer tmb://servera:8000 tmb://serverb:8000 tmb://serverc:8000 -polite

最後のノードが起動されるまで他のすべてのノードが遅延するため、最後のノードを除くすべてのノードは、-politeスイッチを使用して起動することが重要です。

2.2.3 メッセージ・バス・レポート統計の理解

メッセージ・バス・テストのそれぞれの側(クライアントとサーバー)から定期的にパフォーマンス統計がレポートされます。出力例は、リクエストを送信しているクライアントからのものです。

throughput(out 17819msg/s 583mb/s, in 17820msg/s 583mb/s),
   latency(response(avg 51.06us, effective 51.06us, min 43.42us, max 143.68us),
   receipt 53.36us), backlog(out 0% 0/s 0B, in 0% 0/s 0B), connections 1, errors 0

レポートには、前回のレポート以降の統計(now:)と集計した存続期間の統計(life:)の両方が出力されます。

表2-2では、メッセージ・バス統計について説明します。

表2-4 メッセージ・バスの統計

項目	説明
throughput	送受信される1秒当たりのメッセージ量と送信率
latency	メッセージの応答および受信にかかった時間
backlog	送信および処理を待機中のメッセージ数
connections	メッセージ・リスナー間のオープン接続数
errors	失われていることが検出されたメッセージの数。

特に重要な項目は、throughputとlatencyです。目標は、待機時間が長くにならず、可能なかぎり多くのネットワーク帯域幅を使用することです。帯域幅の使用量が少なく、待機時間が長い場合は、TCPの設定のチューニングを検討してください。バックログまたはエラー率が高い場合も、ネットワーク構成の問題を示している可能性があります。ネットワークのチューニングを参照してください。