QPID C++ Client Multi-Thread-Optimierungen

Question

Ich bin auf der Suche nach der besten Möglichkeit, einen C++ Apache QPID-Client für optimale Leistung bei hohem Nachrichtenverkehr herauszufädeln.

Unser Broker wird 3 Vermittlungsstellen mit je 2 unidirektionalen Warteschlangen enthalten. In den 3 "Uplink" -Warteschlangen, auf die der C++ - Client drängen wird, wird es erheblichen Verkehr geben.

Es gibt mehrere wenig dokumentierte Klassen, die als Schnittstelle zum QPID-Broker verwendet werden. Verbindung, Sitzung, Absender und Empfänger. Verbindungen bieten Sitzungen und Sitzungen bieten Absender oder Empfänger. Es ist für mich nach dem Lesen verschiedener QPID-Dokumentationen unklar, welche dieser Objekte threadsicher (oder nicht threadsicher) sind oder zu einem Thread führen, der in der Client-Bibliothek erstellt wird. Gemäß den QPID-FAQ erfolgt das Threading beim Broker auf der Sitzungsebene. Es wird nicht erwähnt, wo es beim Kunden auftritt.

Innerhalb der Client-Anwendung gibt es mehrere Thread-Kontexte, die Daten in eine der Uplink-Warteschlangen übertragen müssen. Ist es am besten, einen Pool von Sitzungen, Verbindungen oder Absendern zu haben, die mehrere Kontexte bedienen? Oder hat QPID für dieses Szenario eine Optimierung eingebaut, was bedeutet, dass 1 gemeinsamer Absender ausreichend wäre?

Ziel ist es, nicht irgendwo einen Engpaß zu haben, sondern parallel mit der vorhandenen Verkehrslast effizient zu skalieren.

Answer 1

Einfädeln im Broker erfolgt unter Verbindung Ebene. I.e. Der gesamte Datenverkehr einer bestimmten Verbindung wird serialisiert und von einem Thread-Pool bedient. Auf dem Client gibt es einen Pool von Threads, die von allen Verbindungen gemeinsam genutzt werden. Anwendungen können selbst Threads erstellen, um die Absender/Empfänger zu steuern. Alle genannten Objekte (Connections, Session, Sender und Receiver) sollen threadsicher sein, jedoch würde ich generell einen Thread pro Sitzung und wahrscheinlich eine Sitzung pro Verbindung als optimal bezeichnen.