Das legt den Schluss nahe, dass nicht das Netzwerk zwischen den Servern der limitierende Faktor ist.
Wir hatten nie einen Publisher im produktiven Einsatz und nur ein recht rudimentäres Testing zu QV 8/9 Zeiten, was echt schon lange her ist. Insofern ist mir die Arbeitsweise der Distribution nicht wirklich ganz klar. Ganz vereinfacht, könnte ich mir folgendes Vorgehen vorstellen: Laden der Anwendung ohne UI in den RAM --> Duplizieren der Anwendung im RAM --> Daten-Reduktion anhand der Reduce-Felder --> Speichern des reduzierten Duplikats im Ziel --> Freigeben des Speichers --> nächste Duplette in der Reihe ...
Ich bin mir aber nicht sicher, ob das wirklich so abläuft oder das über andere Mechanismen erfolgt und inwieweit es hier irgendwelche Konfigurationsmöglichkeiten gibt und/oder ob es hier auch irgendwo Buffer-Logiken gibt. Falls es ähnlich zu meiner obigen Idee funktionieren sollte, wäre das CPU Processing doch eher gering und nur ausreichend RAM erforderlich, um die Anwendung max. zweimal im Speicher vorzuhalten. Der größte Flaschenhals wäre hierbei ganz klar das Netzwerk + Storage. Falls die Anwendung jedoch nicht im RAM dupliziert wird, sondern jedes Mal neu geladen wird, würde das den Traffic sowie das Processing erhöhen - falls auch noch irgendwo gebuffert wird, könnte sich das jedoch auch potenzieren. Hast Du hier nähere Informationen?
Die Ableitung hiervon wäre, mal zu schauen, was sich beim Processing and RAM Verbrauch tut, wenn ein Distributions-Task gestartet wird. Läuft der Task sofort an oder gibt es Wartezeiten? Wie viele Einzel-Prozesse werden gestartet? Wie viele Cores werden verwendet? Ziel ist es, irgendwelche Auffälligkeiten zu finden, wie eventuell nur eine einzelne qvb.exe läuft und nur ein einzelner Core wird verwendet oder aber multiple Prozesse werden gestartet und weisen jeweils kurze Peaks und längere Idle-Zeiten auf oder was auch immer. Für den Anfang reicht hier der Task- und/oder der Ressourcen-Manager sicher aus und falls man was findet könnte man auch noch mal mit dem Process-Monitor draufschauen.
Als am wahrscheinlichsten würde ich ein schlecht funktionierendes Buffering halten oder aber n Waiting-Times zwischen den Loops und/oder ein Queuing zwischen den Loops/Cores passieren ...
