43.3. 他のチューニング
HornetQ では、チューニングを実行できるさまざまな場所があります。
- 非同期送信承認を使用します。耐性メッセージをトランザクションで送信せず、send() へのコールが返されるまでにメッセージがサーバーに到達する保証が必要な場合は、耐性メッセージを送信してブロックするよう設定せずに、非同期送信承認を使用して別のストリームで送り返す承認を取得します。この詳細については、18章送信およびコミットの保証 を参照してください。
- 事前承認モードを使用します。事前承認モードでは、メッセージがクライアントに送信される前に承認されます。
これにより、送信される承認トラフィックの量が削減されます。この詳細については、27章事前承認モード を参照してください。
- 永続化を無効にします。メッセージ永続化が必要ない場合は、
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
でpersistence-enabled
を false に設定してメッセージ永続化を一括して無効にします。 - トランザクションをレイジー状態で同期します。
hornetq-configuration.xml
で、journal-sync-transactional
をfalse
に設定すると、障害発生時にトランザクションが失われることがありますが、トランザクション永続化のパフォーマンスが向上します。詳細については、18章送信およびコミットの保証 を参照してください。 - レイジー状態でトランザクションを使用せずに同期します。
hornetq-configuration.xml
で、journal-sync-non-transactional
をfalse
に設定すると、障害発生時に耐性メッセージが失われることがありますが、非トランザクション永続化のパフォーマンスが向上します。詳細については、18章送信およびコミットの保証 を参照してください。 - メッセージをブロックせずに送信します。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml
(JMS と JNDI を使用している場合) または直接 ClientSessionFactory でblock-on-durable-send
とblock-on-non-durable-send
をfalse
に設定します。したがって、メッセージを送信するごとにネットワーク全体のラウンドトリップを待つ必要がありません。詳細については、18章送信およびコミットの保証 を参照してください。 - 非常に高速なコンシューマーの場合は、consumer-window-size を増加させます。これにより、効果的にコンシューマーフロー制御が無効になります。
- ソケット NIO と古いソケット IO。デフォルトでは、HornetQ はサーバーおよびクライアントサイドで古い方 (ブロッキング) を使用します (詳細については、14章トランスポートの設定 を参照してください)。NIO は非常にスケーラブルですが、古いブロッキング IO と比較してレイテンシーが発生することがあります。サーバーで数千の接続を処理できるように、サーバーでは NIO を使用します。ただし、サーバーでの接続が少ない場合は、サーバーアクセプターに対して古い IO を保持することにより、パフォーマンス上の小さな利点を得ることができます。
- JMS ではなくコア API を使用します。JMS API を使用すると、コア API を使用する場合よりもパフォーマンスが若干低下します。これは、サーバーが処理する前にすべての JMS 操作をコア操作に変換する必要があります。コア API を使用する場合は、
SimpleString
をできるだけ多く取得するメソッドを使用するようにしてください。java.lang.String
とは異なり、SimpleString
は送信前にコピーを必要としません。したがって、コール間でSimpleString
インスタンスを再使用する場合は、不必要なコピーを回避できません。