Wir sind dabei, eine neue App in ihrer Live-Umgebung bereitzustellen.
Auf den App-Servern wird eine von IIS gehostete .NET-Anwendung ausgeführt, die EntityFramework verwendet und zahlreiche Aufrufe an eine Nicht-.NET-COM+-Anwendung tätigt.
Wir konnten die Leistung des reinen .NET-Codes beeinflussen, indem wir die Anzahl der maximalen Arbeitsprozesse im IIS-Anwendungspool geändert haben. Meine Frage ist jedoch, wie sich die Anzahl der Arbeitsprozesse auf die Poolgröße der Anwendungspools in den Komponentendiensten auswirkt. Dinge wie:
- Sollten wir eine 1:1-Beziehung zwischen diesen beiden Werten anstreben?
- Sollten wir mehrere Worker-Threads vermeiden?
Jede Einsicht wird dankbar entgegengenommen ...
Antwort1
Die Anzahl der Arbeitsprozesse in den beiden Pools steht nicht in direktem Zusammenhang. Sie müssen lediglich die Verweildauer in jedem Pool ermitteln. Wenn also die IIS-Arbeitsprozesse ausgelastet sind und nur ein kleiner Teil der Gesamtzeit in der COM-Anwendung verbracht wird, ist es unwahrscheinlich, dass die COM-Threads die Leistung beeinträchtigen.
Versuchen Sie, die Anzahl der aktiven Threads in einer Stresssituation zu messen, um zu bestimmen, wie die Größen der einzelnen Pools gesteuert werden können.
Bedenken Sie auch, dass die IIS-Arbeitsprozesse auch nach anderen Kriterien als der Prozessorauslastung wiederverwendet werden. Dies kann Ihre Fähigkeit, Daten zwischen Aufrufen auszutauschen, erheblich beeinträchtigen und Versuche, die direkte Leistung stark zu beeinträchtigen, untergraben.
Sie sollten die Kosten für die Überbrückung von .NET zu COM senken, indem Sie einen schlanken COM-Wrapper in Betracht ziehen, der mehrere Anforderungen einer einzigen .NET-Abfrage aggregieren kann. Dies kann auch den Nebeneffekt haben, dass mehrere COM-Methoden aus dem Pool in einem einzigen Thread konsolidiert werden.