2010-12-03 15 views
5

Ich entwerfe ein System, das JMS und einige Messaging-Software (ich bin auf ActiveMQ gelehnt) als Middleware verwenden. Es wird weniger als 100 Agenten geben, von denen jeder höchstens 5000 Nachrichten pro Tag durch die Warteschlange schiebt.Beratung zu MoM und großen Nachrichten

Die Nutzlast pro Nachricht beträgt jeweils etwa 100 Byte. Ich erwarte, dass ungefähr die Hälfte (2500) der Nachrichten sich um Mitternacht anhäufen und die andere Hälfte wird während des Tages etwas gleichmäßig verteilt sein. Die oben angegebenen Zahlen sind alle am oberen Ende dessen, was ich erwarte. (Ja, wahrscheinlich werde ich diese Aussage in naher Zukunft essen).

Es gibt eine Art von Nachricht, bei der die Nutzlast wesentlich größer sein wird, etwa im Bereich von 5-50 MB. Diese Nachrichten werden nur wenige Male pro Tag von jedem Agenten gesendet.

Meine Fragen sind: Wird das mir Probleme in irgendeiner Weise dazu führen, oder ist es vollkommen normal, größere Datenmengen über eine Nachrichtenwarteschlange zu senden?

Wird zum Beispiel der Durchsatz verringert (kleinere Nachrichten in der Warteschlange), während die größeren Nachrichten verarbeitet werden?

Oder wird die Nachrichtenwarteschlange bei größeren Nachrichten würgen?

Oder sollte ich das auf eine andere Weise angehen, sagen wir den Standort der Daten über jms senden und den End-Empfänger die Daten an anderer Stelle abholen lassen? (Ich hatte gehofft, wegen Kopplungen, Sicherheitsproblemen und zusätzlicher Konfiguration keinen speziellen Fall zu haben).

Ich bin völlig neu zu den praktischen Details von jms, also sag mir einfach, wenn ich mehr Details zur Verfügung stellen muss.

Bearbeitet: Ich akzeptierte Andres wirklich tolle Antwort. Schreiben Sie weiter Ratschläge und Meinungen, ich werde alles Nützliche auf den neuesten Stand bringen.

Antwort

2

Größere Nachrichten werden definitiv einen Einfluss haben, aber die Größen, die Sie hier erwähnen (5-50 MB), sollten von jedem vernünftigen JMS-Server verwaltet werden können.

Beachten Sie jedoch Folgendes. Während der Verarbeitung einer bestimmten Nachricht wird die gesamte Nachricht in den Speicher gelesen. Wenn also jeweils 100 Agenten eine 50-MB-Nachricht ungefähr zur gleichen Zeit oder zu unterschiedlichen Zeiten an eine andere Warteschlange senden, die Nachrichten jedoch lange dauern, können Sie in eine Situation geraten, in der Sie versuchen, 5000 MB an Nachrichten in den Speicher zu schreiben. Ich bin in der Vergangenheit auf ähnliche Probleme mit 4MB Nachrichten mit ActiveMQ gestoßen, aber es wurden mehr Nachrichten gesendet als die hier erwähnten Zahlen. Wenn die Nachrichten alle an die gleiche (persistente) Warteschlange gesendet werden, sollte dies kein Problem darstellen, da nur die zu verarbeitende Nachricht im Speicher sein muss.

Es hängt also von Ihrer Einrichtung ab. Wenn das theoretische obere Limit von 5000 MB für Sie managbar ist (und das 32-Bit-JVM-Limit von 2000 MB im Auge behält), dann fahren Sie fort, aber dieser Ansatz skaliert eindeutig nicht sehr gut, also würde ich es nicht vorschlagen. Wenn alles in eine beständige Warteschlange geschickt wird, wäre es wahrscheinlich in Ordnung, jedoch würde ich empfehlen, zuerst einen Prototyp unter Last zu setzen, um sicherzugehen. Die Verarbeitung ist möglicherweise langsam, aber nicht unbedingt langsamer, als wenn sie von einem anderen Mechanismus abgerufen wird. In jedem Fall würde ich definitiv empfehlen, die kleineren Nachrichten an separate Ziele zu senden, wo sie parallel zu den größeren Nachrichten verarbeitet werden können.

+0

Super Antwort! Die größeren Nachrichten haben alle den gleichen "Typ" und werden an die gleiche persistente Warteschlange gesendet, also sollte mir das gut gehen. – Ronnis

0

die Nachrichtengröße hat natürlich einen Einfluss auf den Durchsatz (in msgs/s). Je größer die Nachrichten, desto kleiner der Durchsatz.

1

Wir führen ein ähnliches Szenario mit einer größeren Anzahl von Nachrichten. Wir haben es ähnlich dem Andres-Vorschlag gemacht, indem wir verschiedene Warteschlangen für die große Anzahl kleinerer Nachrichten (die in unserem Szenario noch ~ 3-5 MB sind) und die wenigen großen Nachrichten, die etwa 50-150 MB groß sind, verwenden.

Zusätzlich zu den bereits erwähnten Speicherproblemen sind bei der Verarbeitung einer großen Anzahl persistenter großer Nachrichten auch allgemeine Leistungsprobleme beim Nachrichtenbroker aufgetreten. Dies wird durch die Notwendigkeit verursacht, diese Nachrichten irgendwie im Dateisystem zu halten, es kam zu Engpässen auf dieser Seite.

+0

Interessant. Wie hast du es gelöst? – Ronnis

+0

haben wir einige Optimierung der Physik des Dateisystems durchgeführt und zusätzlich ein Provider-spezifisches Cluster-Szenario verwendet und den Nachrichten-Broker auf 4 Hosts verteilt. – roundrobin