activemqを最適化する方法

Question

私は、Javaでのサーバーの過負荷のシミュレーションでActiveMQを使用しています。そして主にそれは大丈夫ですが、私が600以上のリクエストを受け取ったとき、物事はWTFに行くだけです！

ボトルネックは、以下のこの男である私のマスターサーバーだと思います。接続を再利用し、さまざまなセッションを作成して、クライアントからのメッセージを消費しています。前述のように、接続ごとに約50〜70セッションを使用し、接続とキューを再利用しています。以下のコンポーネント/リスナーの再利用/最適化のアイデアはありますか？

アーキテクチャは次のとおりです。

* =さまざまな

クライアント---＆gt; JMS MasterQueue ---＆gt; *マスター---＆gt; JMS SlavaQueue ---＆gt; * SlaveQueue

主に、マスターのセッションごとに一時キューを作成しています-＆gt;スレーブ通信、それはパフォーマンス上の大きな問題ですか？

/**
 * This subclass implements the processing log of the Master JMS Server to
 * propagate the message to the Server (Slave) JMS queue.
 *
 * @author Marcos Paulino Roriz Junior
 *
 */
public class ReceiveRequests implements MessageListener {
    public void onMessage(Message msg) {
        try {
            ObjectMessage objMsg = (ObjectMessage) msg;

            // Saves the destination where the master should answer
            Destination originReplyDestination = objMsg.getJMSReplyTo();

            // Creates session and a sender to the slaves
            BankQueue slaveQueue = getSlaveQueue();
            QueueSession session = slaveQueue.getQueueConnection()
                    .createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
            QueueSender sender = session
                    .createSender(slaveQueue.getQueue());

            // Creates a tempQueue for the slave tunnel the message to this
            // master and also create a masterConsumer for this tempQueue.
            TemporaryQueue tempDest = session.createTemporaryQueue();
            MessageConsumer masterConsumer = session
                    .createConsumer(tempDest);

            // Setting JMS Reply Destination to our tempQueue
            msg.setJMSReplyTo(tempDest);

            // Sending and waiting for answer
            sender.send(msg);
            Message msgReturned = masterConsumer.receive(getTimeout());

            // Let's check if the timeout expired
            while (msgReturned == null) {
                sender.send(msg);
                msgReturned = masterConsumer.receive(getTimeout());
            }

            // Sends answer to the client
            MessageProducer producerToClient = session
                    .createProducer(originReplyDestination);
            producerToClient.send(originReplyDestination, msgReturned);
        } catch (JMSException e) {
            logger.error("NO REPLY DESTINATION PROVIDED", e);
        }
    }
}

Answer 1

まあ、読んでから最適化の方法を見つけました。

送信者やtempqueueなどのセッション変数を再利用する必要があります。新しいものを作成する代わりに。

別のアプローチでは、このリンクに従って、Javaのスレッドのスタックサイズを小さくします。 ActiveMQ OutOfMemoryはこれ以上スレッドを作成できません

Answer 2

リスナースレッドプールの構成に関係している可能性があります。リスナーが1秒あたり特定のしきい値までの要求をタイムリーに処理し、着信要求を処理できるが、そのレートを超えると遅れが生じ始める可能性があります。着信リクエストごとに行われた作業、着信リクエストレート、各リスナーが使用できるメモリとCPU、割り当てられたリスナーの数に依存します。

これに該当する場合、キューを監視し、着信メッセージの数がいつバックアップを開始するかを確認できるはずです。これは、リソースとリスナーの数を増やして効率的に処理する必要があるポイントです。