4

Java でのサーバーの過負荷のシミュレーションで ActiveMQ を使用しています。そして、基本的にはうまくいきますが、600 件を超えるリクエストを受け取ると、どうしようもありません。

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

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

* = いろいろ

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

主にMaster→Slave通信のセッションごとにTemp Queueを作っているのですが、性能的に大きな問題はありますか？

/**
 * 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);
        }
    }
}
4

2 に答える 2

2

さて、いくつか読んだ後、私は最適化する方法を見つけました。

送信者や一時キューなど、いくつかのセッション変数を再利用する必要があります。新しいものを作成する代わりに。

別のアプローチは、Javaのスレッドのスタックサイズを小さくして、このリンクを たどりますActiveMQOutOfMemoryこれ以上スレッドを作成できません

于 2009-11-28T15:19:18.493 に答える
1

リスナー スレッド プールの構成に関係している可能性があります。1 秒あたりの要求数が一定のしきい値までは、リスナーは受信要求をタイムリーに処理し続けることができますが、その速度を超えると遅れが生じ始めます。これは、着信リクエストごとに実行される作業、着信リクエストのレート、各リスナーが使用できるメモリと CPU、および割り当てられたリスナーの数によって異なります。

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

于 2009-11-26T00:02:56.043 に答える