Protokollpufferung über MSMQ an den WCF-Webdienst

Question

Ich habe eine interessante Situation in meinen Händen. Seit einigen Jahren hatten wir einen WCF-Dienst, der auf einem IIS-Feld in unserem Netzwerk ausgeführt wird, das wir zur Protokollierung verwenden. Anwendungen Verwenden Sie BASICHTTPBINDING, um Protokollnachrichten zu senden, und es protokolliert sie in einer Datenbank. Die meisten Protokollierung aller anderen Anwendungen sind auf ein paar Dutzend Protokolle pro Betrieb begrenzt. Vor kurzem haben wir eine andere Anwendung, um diesen Protokollierungsdienst zu verwenden. Diese Anwendung meldet sich ziemlich aggressiver an als alle anderen Clients für unseren Protokollierungsdienst. Es hat eine Operation, die sich während des Kurses über 100.000 Nachrichten protokollieren könnte (dies ist zum Importieren von 100.000 Datensätzen über die CSV-Datei).

beim Versuch, einen Weg zu finden, um diesen Lauf effizienter zu gestalten, wurde vorgeschlagen, dass ich MSMQ versuche, die Protokollanforderungen zu wenden und auf dem Dienst weiterzuleiten, anstatt die Anwendung direkt mit dem Protokollierungsdienst zu kommunizieren (Anforderung wurde in einem separaten Thread für Leistungszwecke gesendet). Auf diese Weise ist die Anwendung nicht gesperrt, während das Protokoll geschrieben wird. Ich habe einen Nachweis des Konzeptnachweises für diese MSMQ-Lösung auf meinem örtlichen Maschinen implementiert, aber da ich noch nie MSMQ benutzt habe, und da ich nur jetzt lerne, was sein Platz technologisch ist, finde ich mich mit vielen Fragen und wenigen Antworten . Ich hoffe, dass jemand mich auf einige kurze Informationen darüber zeigen kann, wie MSMQ funktioniert, damit ich diesen Nachweis des Konzepts besser debuggen kann, den ich geschrieben habe.

Was ich nach der Implementierung von MSMQ sehe:

• meine Anwendung, die die Protokolle sendet MSMQ kehrt fast sofort zurück (anstatt auf das Protokoll zu warten begangen werden), was ich will.
• obwohl ich 1000-Protokolle an das geschickt habe MSMQ-Anwendung in weniger als 30 Sekunden, es dauert einige Minuten Alle 1000 Meldungen, um es in die Datenbank. Es erscheint als meine Warteschlange hat eine Art Drossel Aktiviert, wo es das zurückhält Protokollanforderungen, aber ich weiß nicht, wie Sie das überprüfen.
• Wenn ich net.tcp auf dem Server benutze, der die Protokolle vom MSMQ-Dienst empfängt, bekomme ich eine Menge Service-Timeout-Fehler und nur 90% (oder so) der Protokolle schaffen es in der Datenbank, aber wenn ich Baseichtpbinding verwendet zuverlässig.

  Hier ist der Code in meinem MSMQ-Dienst: generasacodicetagpre.

  Hier ist der Code von mir, der den MSMQ-Dienst erstellt generasacodicetagpre.

  Hier ist der Code in der Anwendung, den ich den MSMQ-Dienst anrufen möchte: generasacodicetagpre.

  Ich schätze jegliche Hilfe, die jemand anbieten kann. Ich bin ein bisschen verloren, was für genau das, welche Funktionen für MSMQ zur Verfügung stehen. Ich habe 6 oder so Stunden über Google durchgeführt. Die meisten Docs, die ich gefunden habe, sind ziemlich alt (2007) und sind ein hartes Lesen. Vielleicht erwarten sie, dass ich etwas Kenntnissgrad zu diesem Thema habe.

Answer 1

What you're seeing (if you're using net.msmq binding on your WCF) is what is designed to happen.

MSMQ, as a store-and-forward facility, will store messages in a queue at the sending client and the receiving server until either network or processing bandwidth is available. What this does is take load off the client (as you've observed) by making the process asynchronous.

You can view the statuses of the queues using Performance Monitor, the number of messages in the outbound queue (at the client) and the server queue are written to performance counters in realtime and can be viewed and/or logged.

If the performance is sub-optimal, you could look to change the WCF throttling settings to allow more concurrent connections in your service behaviour.

e.g.

<serviceThrottling
         maxConcurrentCalls="20"
         maxConcurrentSessions="20"
         maxConcurrentInstances="20"
       />