2015-01-06 4 views
16

Ich habe einige einfachen Test für den Vergleich und ein paar Informationen gemacht, die ich herausgefunden wurdeHttpclient vs HttpWebRequest für eine bessere Leistung und Sicherheit und weniger Verbindungen

Einzelhttpclient konnte durch mehrere Anfrage geteilt werden, wenn geteilt und die Anforderungen sind zu das gleiche Ziel, mehrere Anfrage könnte die Verbindungen wiederverwenden WebRequest muss die Verbindung für jede Anfrage neu erstellen.

Ich sah auch eine Dokumentation auf andere Weise nach oben Httpclient-Beispiel

Der folgende Artikel fasst die High-Speed-NTLM-authentifizierte Verbindung teilen

HttpWebRequest.UnsafeAuthenticatedConnectionSharing

Mögliche Implementierungen, die ich ausprobiert verwenden sind unten gezeigt

A)

private WebRequestHandler GetWebRequestHandler() 
{ 
    CredentialCache credentialCache = new CredentialCache(); 
    credentialCache.Add(ResourceUriCanBeAnyUri, "NTLM", CredentialCache.DefaultNetworkCredentials); 
    WebRequestHandler handler = new WebRequestHandler 
    { 
     UnsafeAuthenticatedConnectionSharing = true, 
     Credentials = credentialCache 
    }; 

    return handler; 
} 

using (HttpClient client = new HttpClient(GetWebRequestHandler(), false)) 
{ 
} 

B)

using (HttpClient client = new HttpClient) 
    { 
    } 

C)

HttpWebRequest req = (HttpWebRequest)WebRequest.Create("some uri string") 

ich Hilfe bei der Herstellung von mir, welcher Ansatz verstehen würde schätzen sollte ich nehmen, um maximale Leistung und minimiert Verbindungen zu erreichen und sicherzustellen, dass Sicherheit nicht betroffen.

+0

Httpclient ist das neue cool Kind in der Stadt, und es ist angeblich die beste von allen, async/Aufgaben unterstützt, und ist viel mehr tragbar als andere (es gibt auch WebClient). Es erfordert jedoch .NET 4.5+. Davon abgesehen, denke ich nicht, dass Sie bei richtiger Anwendung große Unterschiede in Bezug auf die rohe Leistung sehen sollten. –

+1

Ich benutze HttpClient einen Blick auf diesen Beitrag [Sie verwenden HTTPCLIENT falsch und es ist Ihre Software DESTABILISIEREN] (http://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/) –

+0

auf jeden Fall gehen Mit HttpClient, abgesehen von der Tatsache, dass es Verbindungspooling unterstützt, async/erwarten out of the Box, bietet es mehr Flexibilität über sie Handler und ist auch einfacher zu Komponententests mit HttpClient schreiben. – Duy

Antwort

7

Wenn Sie beide mit async verwenden, sollte dies für den Leistungspunkt gut sein, da die Ressourcen, die auf die Antwort warten, nicht blockiert werden und Sie einen guten Durchsatz erhalten.

HttpClient wird gegenüber HttpWebRequest bevorzugt, da die asynchronen Methoden standardmäßig zur Verfügung stehen und Sie sich keine Gedanken über das Schreiben von Anfangs-/Ende-Methoden machen müssen.

Wenn Sie einen asynchronen Anruf verwenden (mit einer der beiden Klassen), blockiert er grundsätzlich nicht die Ressourcen, die auf die Antwort warten, und jede andere Anforderung würde die Ressourcen für weitere Anrufe nutzen.

Eine weitere Sache, die Sie nicht vergessen sollten, dass Sie HttpClient nicht im 'using'-Block verwenden sollten, um die Wiederverwendung derselben Ressourcen für andere Webanforderungen immer wieder zu ermöglichen.

Für weitere Informationen siehe

Do HttpClient and HttpClientHandler have to be disposed?

+0

Yep, gerade über die Entsorgung von HttpClient selbst gelernt. Scheint jetzt die große Diskussion zu sein. Lange Rede, kurzer Sinn, entsorgen Sie es nicht! – trnelson

0
  1. Es gibt ein Problem in Ihrer Implementierung 'A' folgende Threads. Die Lebensdauer der von GetWebRequestHandler() zurückgegebenen Instanz ist kurzlebig (vielleicht nur für das Beispiel?). Wenn dies mit Absicht gemacht wurde, negiert es das Passieren von false für den 2. Param des HttpClient Konstruktors. Der Wert false weist den HttpClient an, die zugrunde liegende HttpMessageHandler nicht zu entfernen (was bei der Skalierung hilft, da der Port für die Anforderung nicht geschlossen wird). Dies setzt natürlich voraus, dass die Lebensdauer des HttpMessageHandler lange genug ist, damit Sie den Vorteil nutzen können, dass Ports nicht geöffnet/geschlossen werden (was einen großen Einfluss auf die Skalierbarkeit Ihres Servers hat). Daher habe ich eine Empfehlung der Option "D".

  2. Es gibt auch eine Option "D", die Sie oben nicht aufgelistet haben - um die Httpclient Instanz static Instanz zu machen und über alle API-Aufrufe hinweg wiederzuverwenden. Dies ist aus Speicherzuweisung und GC-Perspektive viel effizienter - ebenso wie das Öffnen von Ports auf dem Client. Sie haben nicht den Aufwand, Speicher für HttpClient Instanzen (und alle darunter liegenden Objekte) zuzuweisen und zu erstellen und somit die Bereinigung über GC für sie zu vermeiden.

Bitte lesen Sie meine Antwort über eine ähnliche Frage zur Verfügung gestellt - What is the overhead of creating a new HttpClient per call in a WebAPI client?