2009-11-25 7 views
3

J'utilise ActiveMQ sur une simulation de surcharge de serveurs en Java. Et surtout cela va bien, mais quand je reçois plus de 600 demandes, la chose va juste WTF!Comment optimiser activemq

Je pense que le goulot d'étranglement est mon serveur maître qui est ce type ci-dessous. Je réutilise déjà la connexion et crée plusieurs sessions pour consommer les messages des clients. Comme je l'ai dit, j'utilise environ 50-70 sessions par connexion, réutilisant la connexion et la file d'attente. Toute idée de ce que je peux réutiliser/optimiser de mes composants/écouteurs ci-dessous?

L'architecture est le suivante:

* = divers

client ---> JMS MasterQueue ---> * Maître ---> JMS SlavaQueue ---> * SlaveQueue

Principalement, je suis en train de créer une file d'attente temporaire pour chaque session de Maître -> Communication esclave, est-ce un gros problème de performance?

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

Répondre

2

Eh bien, après quelques lectures j'ai découvert comment optimiser.

Nous devrions réutiliser certaines variables de session, telles que l'expéditeur et la tempqueue. Au lieu d'en créer de nouveaux.

Une autre approche est mise de la taille de la pile pour le fil en Java inférieur, suivant ce lien ActiveMQ OutOfMemory Can't create more threads

1

Il peut s'agir de la configuration du pool de threads de l'écouteur. Il se peut que jusqu'à un certain nombre de requêtes par seconde, l'auditeur puisse suivre et traiter les demandes entrantes en temps voulu, mais au-delà, il commence à prendre du retard. cela dépend du travail effectué pour chaque requête entrante, du débit de la demande entrante, de la mémoire et de l'unité centrale disponibles pour chaque auditeur, et du nombre d'écouteurs alloués. Si cela est vrai, vous devriez pouvoir regarder la file d'attente et voir quand le nombre de messages entrants commence à sauvegarder. C'est le point où vous devez augmenter les ressources et le nombre d'auditeurs pour traiter efficacement.

+0

donc ma meilleure approche est mis plus d'auditeurs là le maître? –

+0

Si c'est ce que vos données vous disent, alors oui. La seule façon de savoir ce qui se passe est d'observer les files d'attente et de mesurer les auditeurs. – duffymo