Schnell Hintergrund: Ich verstehe, dass HTTPListener http.sys Kernel-Treiber verwendet, die es angeblich zu einem großen Darsteller macht. Bei einigen Leistungsbenchmarks zwischen einem verwalteten http-Server und einem nativen vc ++ -Server sehe ich jedoch auf der nativen Seite einen Anstieg von ca. 15 MB / s. Test-Setup ist zwei Labormaschinen frisch mit 1gb NICS formatiert. Auf der nativen Seite sehe ich etwa 110 MB / s, was fast 100% des nic minus Overheads ist, wenn ich HTTP-Listener verwende, sehe ich ~ 94 MB / s (max. 100).
Die Tests sind Äpfel mit Äpfeln,
Insgesamt erwarte ich, dass ich über HTTPListener nahe an die 110 MB / s des nativen Servers kommen kann, 15 MB / s scheint ziemlich teuer.
Fragen: 1. Gibt es andere Optimierungen für die Verwaltung, die ich vermisse? 2. Was sind mögliche Engpässe, ich sah den HTTPResponseStream über Reflektor, sieht aus wie einige Marshalling geht, aber keine grellen Probleme, tatsächlich bei der Verwendung von Chunking produziert es ein identisches Chunk-Array wie mein nativer Server.
Irgendwelche Ideen werden geschätzt,
Die Tatsache, dass Http.sys verwendet wird, bedeutet nicht, dass kein native-to-managed-Übergang vorhanden ist. Aus dem oben genannten MSDN-Artikel:
HTTP.sys bietet Verbindungsverwaltung, Bandbreitendrosselung und Webserverprotokollierung.
Aufgrund der Tatsache, dass Sie verwalteten Code ausführen, haben Sie Interop (nativ zu verwaltet, nicht mit COM-Interop zu verwechseln), Sie haben Garbage Collection, etc. Es wird nie so schnell wie ein reines natives sein C ++ Implementierung.
BEARBEITEN: Um dies zu verdeutlichen, führen Sie immer noch einen .NET-Prozess aus. Sie hängen nur an IIS im Kernel-Modus, nicht im Benutzer-Modus. Ein großartiger Artikel dazu ist hier: Ссылка
Tags und Links .net performance httplistener