Während ich den zeromq-Guide gelesen habe, bin ich auf einen Client-Code gestoßen, der 100k Anfragen in einer Schleife sendet und dann die Antwort in einer zweiten Schleife erhält.
%Vor%Ich habe einen Zähler hinzugefügt, um die Anzahl der Antworten zu zählen, die der Worker (test_worker.c) an den Broker sendet, und einen weiteren Zähler in mdp_broker.c, um die Anzahl der Antworten zu zählen, die der Broker an einen Client sendet. Beide zählen bis zu 100k, aber der Client empfängt nur etwa 37k Antworten.
Wenn die Anzahl der Client-Anfragen auf etwa 40.000 eingestellt ist, werden alle Antworten empfangen. Kann mir jemand sagen, warum warum Pakete verloren gehen , wenn der Client mehr als 40.000 asynchrone Anfragen sendet?
Ich habe versucht, die HWM auf 100k für den Broker-Socket zu setzen, aber das Problem besteht weiterhin:
%Vor%Ohne das HWM zu setzen und die Standard-TCP-Einstellungen zu verwenden, wurde Paketverlust mit nur 50 KB Nachrichten verursacht.
Folgendes half, den Paketverlust beim Broker zu verringern:
Das half nur bis zu einem gewissen Punkt. Mit zwei Clients, von denen jeder 100.000 Nachrichten schickte, war der Broker in der Lage, gut zu verwalten. Aber als die Anzahl der Clients auf drei erhöht wurde, hörten sie auf alle Antworten zu erhalten.
Schließlich hat es mir geholfen, keinen Paketverlust sicherzustellen, indem ich das Design des Client-Codes folgendermaßen ändere:
Sie senden 100.000 Nachrichten und beginnen dann, sie zu empfangen. Daher sollten die 100k Nachrichten in einem Puffer gespeichert werden. Wenn der Puffer erschöpft ist und keine Nachrichten mehr speichern kann, erreichen Sie die High Watermark des ZeroMQ. Verhalten bei High Water Mark ist in ZeroMQ-Dokumentation angegeben.
Im Fall des oben genannten Codes kann der Broker einige der Nachrichten verwerfen, da ein Majordomomakler die Nachrichten verwendet ROUTER-Socket . Eine der Auflösungen würde die Sende- / Empfangs-Schleifen in getrennte Threads aufteilen
In ZeroMQ v2.1 war ein Standardwert für ZMQ_HWM INF (unendlich), was dazu beitrug, dass der Test etwas aussagekräftig war, aber auf Kosten von Das Risiko eines Speicherüberlaufs stürzt stark ab, da die Pufferzuweisungsrichtlinie nicht eingeschränkt / kontrolliert wurde, um ein physikalisches Limit zu erreichen.
Ab ZeroMQ v3.0 +, ZMQ_SNDHWM / ZMQ_RCVHWM standardmäßig auf 1000, die anschließend eingestellt werden können.
Sie können auch eine explizite Warnung lesen, dass
ØMQ garantiert nicht, dass der Socket so viele ZMQ_SNDHWM-Nachrichten akzeptiert, und das tatsächliche Limit kann abhängig vom Nachrichtenfluss auf dem Socket um bis zu 60-70% niedriger sein als / p>
Nein.
Ja, stellen Sie für Demo-Test-Experimente wieder unendliche Hochwassermarken ein, aber seien Sie vorsichtig, diese Praxis in jeder Software für die Produktion zu vermeiden.
Wie oben erwähnt, scheint der ursprüngliche Demo-Test in seiner Version 2.1 eine gewisse Bedeutung zu haben.
Seitdem hat sich ZeroMQ sehr weiterentwickelt. Eine sehr nette Lektüre für Ihr besonderes Interesse an Performance-Umschlägen, die Ihnen vielleicht einen weiteren Einblick in diese Domain geben, finden Sie Schrittleitfaden mit Codebeispielen zu ZeroMQ-Protokoll-Overheads / Performance-Fallstudie zu großen Dateiübertragungen
... wir haben bereits ein Problem: Wenn wir zu viele Daten an den ROUTER-Socket senden, können wir sie leicht überlaufen lassen. Die einfache aber dumme Lösung besteht darin, eine unendliche Hochwassermarke auf die Steckdose zu setzen. Es ist dumm, weil wir jetzt keinen Schutz gegen das Erschöpfen des Serverspeichers haben. Doch ohne eine unendliche HWM riskieren wir, große Dateien zu verlieren.
Versuchen Sie Folgendes: Setzen Sie den HWM auf 1.000 (in ZeroMQ v3.x ist dies der Standardwert) und reduzieren Sie dann die Chunk-Größe auf 100K, sodass wir 10K Chunks auf einmal versenden. Führen Sie den Test aus, und Sie werden sehen, dass es nie beendet wird. Wie die zmq_socket () - Manpage mit fröhlicher Brutalität für den ROUTER-Socket sagt: "ZMQ_HWM option action: Drop".
Wir müssen die Datenmenge kontrollieren, die der Server im Voraus sendet. Es hat keinen Sinn, mehr zu senden, als das Netzwerk verarbeiten kann. Versuchen wir einmal, einen Block nach dem anderen zu senden. In dieser Version des Protokolls wird der Client explizit sagen: "Gib mir Chunk N", und der Server wird diesen bestimmten Chunk von der Festplatte abrufen und senden.
Der beste Teil ist, soweit ich weiß, in dem kommentierten Fortschritt der resultierenden Leistung zur Flusskontrolle "Modell 3", und man kann eine Menge von den großen Kapiteln und den realen Bemerkungen im ZeroMQ Guide lernen .
Tags und Links distributed-computing zeromq