Quali misure possono essere prese per ottimizzare Tibco JMS per essere più performanti?

Question

Stiamo utilizzando un sistema di throughput elevato che utilizza TIBCO-EMS JMS per superare un numero elevato di messaggi da e verso il nostro server principale alle nostre connessioni client.Abbiamo fatto alcune statistiche e abbiamo determinato che JMS è il causare molta latenza.Come possiamo rendere Tibco JMS più performante?Ci sono risorse che danno una buona discussione su questo argomento.

Answer 1

L'utilizzo di messaggi non persistenti è un'opzione se non hai bisogno della persistenza. Si noti che anche se hai bisogno di perseveranza, a volte è meglio utilizzare messaggi non persistenti, e in caso di schianto eseguire un'azione di recupero diversa (come risvegliare tutti i messaggi)

Questo è rilevante se:

.
• I crash sono rari (come il recupero richiede tempo)
• Puoi facilmente rilevare un crash
• È possibile gestire i messaggi duplicati (potresti non sapere esattamente quali messaggi sono stati consegnati prima del crash

  EMS fornisce anche alcuni meccanismi che sono persistenti, ma meno prove di proiettile, quindi la classica consegna garantita Questi includono:

  .
  • invece di una consegna dei messaggi "esattamente una volta" è possibile utilizzare "almeno una volta" o "fino a una volta".
  • È possibile utilizzare il meccanismo pre-recupero che fa sì che il client possa recuperare i messaggi alla memoria prima della richiesta dell'applicazione.

Answer 2

EMS non dovrebbe essere il collo della bottiglia. Ho fatto il test e abbiamo ottenuto uno shirtload di throughput sul nostro server.

È necessario provare a determinare dove è il collo della bottiglia. È il problema nel produttore del messaggio o del consumatore. I messaggi vengono accumulati sulla coda.

Che tipo di scenario stai facendo.

Pub / sup o richiesta risposta? stai avendo un accumulo di coda temporanea. Troppe code temporanee possono causare problemi di prestazione. (Soprattutto quando si attardano perché non hai chiuso qualcosa di corretto)

Stai pubblicando a un argomento con abbonati durevoli se sì. Prova a colmare l'argomento in coda e leggere da quelli. Gli abbonati durevoli possono causare anche un piccolo singhiozzo nelle prestazioni poiché deve tracciare chi ha copie di tutti i messaggi.

Assicurarsi che il processo di invio abbia una sessione e più chiamate attraverso quella sessione. Non aprire una sessione completa per ogni operazione. Riutilizzare dove possibile. Fai lo stesso per il consumatore.

Assicurati di chiudere quando hai finito. EMS non chiarisce le cose. Quindi se fai una connessione e basta chiudere la tua app che la connessione è ancora lì e succhia le risorse.

Rivedi la tua tolleranza per messaggi persi in un incidente. Se stai facendo ACK CLIENT e non importa se si blocca l'elaborazione del messaggio, quindi passa a AUTO. Inoltre, credo se stai usando (TEMS - TIBCO EMS per WCF) c'è un problema con il riconoscimento della sessione. Quindi un messaggio è solo quando è stato elaborato su tutto il messaggio, passammo da client ACK a quello che ha avuto dupli ok e ha funzionato meglio)