我正在使用ActiveMQ模拟Java中的服务器重载。主要是好的,但是当我收到超过600个请求时,就会发生WTF!
我认为瓶颈是我的主服务器,这是下面这个人。我已经在重用连接并创建各种会话以使用来自客户端的消息。就像我说的,我每个连接使用大约50-70个会话,重用连接和队列。知道我可以在下面重用/优化我的组件/监听器吗?
架构如下:
* =各种
客户端---> JMS MasterQueue ---> *大师---> JMS SlavaQueue ---> * SlaveQueue
主要是我为每个Master会话创建一个临时队列 - >奴隶沟通,这是性能上的一个大问题吗?
/**
* 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);
}
}
}
答案 0 :(得分:2)
好吧,经过一些阅读后,我发现了如何优化。
我们应该重用一些会话变量,例如sender和tempqueue。而不是创造新的。
另一种方法是在此链接之后将Java中线程的堆栈大小降低 ActiveMQ OutOfMemory Can't create more threads
答案 1 :(得分:1)
它可能与侦听器线程池的配置有关。可能是每秒最多一定数量的请求,监听器能够及时跟上并处理传入的请求,但是高于该速率它开始落后。它取决于为每个传入请求所做的工作,传入的请求速率,每个侦听器可用的内存和CPU以及分配的侦听器数量。
如果是这样,您应该能够查看队列并查看传入消息的数量何时开始备份。这就是你需要增加资源和有效处理的监听器数量的时刻。