Servicemix ActiveMQ problème de performance

Question

J'utilise apache servicemix et apache activeMQ dans mon produit. Ici, dans le cas de HttpConnector j'ai trouvé un problème de performance.

Si j'augmente le nombre de demandes totales à la fois, alors que le nombre augmente, la file d'attente d'échange reste bloquée sur l'un des composants. Une fois que toutes les demandes ont commencé à être traitées, la plus grande partie de l'échange est bloquée sur le composant final ou sur le composant dispatcher *. La taille du tas du conteneur atteint très haut et après un certain temps il plante et redémarre automatiquement.

J'ai aussi utilisé transactionmanager. flowname est également mentionné comme jms.

besoin d'une solution urgent.

Answer 1

Vous pouvez essayer d'utiliser KahaDB au lieu de "amqPersistenceAdapter". Nous avons vu une énorme augmentation de débit juste en passant à cela.

voici la configuration que nous avons utilisé (qui dépend fortement de votre application, mais assurez-vous que « enableJournalDiskSyncs » est réglé sur false)

<persistenceAdapter> 
     <kahaDB directory="../data/kaha" 
      enableJournalDiskSyncs="false" 
      indexWriteBatchSize="10000" 
      indexCacheSize="1000" /> 
    </persistenceAdapter> 

Answer 2

Si j'augmente le nombre total de requêtes à la fois, alors que le nombre augmente, la file d'attente d'échange reste bloquée sur l'un des composants.

ActiveMQ a un mécanisme pour arrêter les messages d'écriture à la production, il est appelé « controll de flux », semble que vous producteur est plus rapide que le consommateur (ou le consommateur n'est pas stable, il sa vitesse), donc d'abord vérifier la configuration memoryLimit pour votre AMQ (en le définissant aussi ou en file d'attente spéciale possible). Essayez de l'augmenter.

<destinationPolicy> 
    <policyMap> 
    <policyEntries> 

     <policyEntry topic="FOO.>" producerFlowControl="false" memoryLimit="1mb"> 
     <dispatchPolicy> 
      <strictOrderDispatchPolicy/> 
     </dispatchPolicy> 
     <subscriptionRecoveryPolicy> 
      <lastImageSubscriptionRecoveryPolicy/> 
     </subscriptionRecoveryPolicy> 
     </policyEntry> 

    </policyEntries> 
    </policyMap> 

En outre, vous pouvez désactiver cette arrêt de traitement des messages entrants avec option producerFlowControl="false". Ainsi, dans le cas où tout le tampon sera utilisé, AMQ ralentira et tous les messages seront stockés en HD. Plus d'infos Producer Flow Control et Message Cursors

taille du tas de conteneur atteint de très haut et après un certain temps, il se bloque et redémarre automatiquement.

Mais de toute façon, il est juste de façon tunning de votre application, il n'est pas la solution, car toujours vous aurez le cas lorsque certaines ressources à court :)

Vous devez limiter les requêtes entrantes ou l'équilibre eux fe en utilisant Pound