Rabbitmq - Prestazioni / aspettative di scala ragionevoli

13

Le sarei grato se qualcuno potesse indicarmi alcune figure / limitazioni su scala ragionevole su rabbitmq (su hardware "medio", prima guerra) o pubblicare la tua esperienza con le sue prestazioni. Sto cercando di ottenere un senso di capacità per il numero di code, il numero di abbonati nelle code, le implicazioni in termini di prestazioni di avere centinaia o migliaia di ascoltatori nelle code di fanfara, tutti i numeri difficili che chiunque potrebbe avere in esecuzione in un coniglio in un ambiente ad alta capacità.

performance rabbitmq

— user21640
fonte

Questo è estremamente semplice da testare, soprattutto considerando che, con i numeri che ti aspetti, hai un budget per preparare alcune VM. Consiglio vivamente di testarlo in base al tuo caso d'uso esatto, all'hardware che ti aspetteresti di utilizzare.

— Andrew M.

Dai un'occhiata ai piani di CloudAMQP : questi sono numeri di prestazioni testati per alcune configurazioni hardware.

— Ripristina Monica - M. Schröder il

11

Prima di tutto, devi capire quali elementi del tuo elenco hanno limiti di ridimensionamento che potresti raggiungere e quali no. Alcuni di questi dipendono dall'implementazione, quindi aiutano a leggere gli interni, ad esempio il libro RabbitMQ in azione.

Il numero di code è limitato dalla RAM. Il numero di messaggi in riproduzione, d'altra parte, non è limitato dalla RAM perché RabbitMQ li espone automaticamente al disco. Una volta ho accidentalmente ricevuto quasi 8 milioni di messaggi in gioco su un server di sviluppo quando non stavo prestando attenzione.

Non ci sono limiti alle dimensioni dei messaggi, ma dovresti davvero pensarci due volte se la dimensione di un singolo messaggio supera 512K. Ho finito per usare una cache di memoria per passare oggetti di grandi dimensioni tra le applicazioni e ho inviato solo messaggi di controllo più piccoli che includevano una chiave memcache. Ma se vuoi davvero puoi inviare enormi messaggi di JPEG e oggetti binari come file JAR come messaggi.

Il numero di abbonati è un limite del sistema operativo perché un abbonato deve aprire almeno un socket TCP. Naturalmente questo è sintonizzabile nella maggior parte dei sistemi operativi, quindi il tuo chilometraggio varierà ed è per questo che devi testare il tuo modello. Ho usato JMETER per caricare test delle nostre applicazioni web e ho appena scoperto questo plugin AMQP https://github.com/jlavallee/JMeter-Rabbit-AMQP ma non l'ho ancora usato. In ogni caso, questo è il tipo di test che ti dirà rapidamente quale sarà il tuo hardware (o configurazione della VM) ragionevolmente gestito.

L'unica cosa difficile che hai è testare un gran numero di consumatori sulle code fanout. Potresti anche voler confrontare utilizzando uno scambio di argomenti, con i consumatori che si abbonano utilizzando una chiave di associazione jolly (*) che ottiene lo stesso risultato finale. Prova a eseguire questo test con il maggior numero possibile di macchine diverse per assicurarti di non essere in qualche modo impegnato in un collo di bottiglia causato da un singolo server che esegue processi consumer. PS che sembra che il plugin Jmeter possa anche essere utile per simulare i consumatori.

— Michael Dillon
fonte

6

Questa non è una vera domanda: ci sono troppi fattori (la definizione mobile di hardware "medio", la dimensione dei messaggi in coda, il numero di utenti e la frequenza con cui sondano / quanto velocemente completano il lavoro nei messaggi, ecc. .). Hai davvero bisogno di confrontare il tuo ambiente.

Detto questo, dai un'occhiata ad alcune di queste discussioni sulle prestazioni di RabbitMQ (tra cui alcune idee su come puoi confrontare la tua installazione per vedere cosa puoi aspettarti da Rabbit):

— voretaq7
fonte

1

Sono consapevole delle molte variabili. Ecco perché ho citato cose come l'hardware "medio", tra virgolette quando capisco quanto sia confusa un'idea. Tuttavia, ho pensato che alcuni numeri derivati dalle esperienze delle persone sarebbero stati utili. Grazie per i riferimenti.

— user21640

1

@ user21640 Non è solo l'hardware che aggiunge fuzz alla tua domanda: il trading ad alta frequenza può avere un'idea diversa di "alta capacità" rispetto a te o io e definizioni molto diverse di prestazioni accettabili. In definitiva, l'unica persona la cui esperienza è importante per te, nel tuo ambiente e nella mia esperienza un benchmark locale ben pianificato vale migliaia di report esterni quando si tratta di fiducia nella pianificazione della capacità - non si sa mai quando il carico di lavoro è IL caso patologico: -)

— voretaq7