Wer mit dem .NET-Framework arbeitet und ab und an HttpWebRequest benutzt, wird vielleicht schon einmal über das Phänomen gestolpert sein, dass Abfragen mittels der HttpWebRequest Klasse, je nach Fall, ziemlich langsam sein können. Vor allem, wenn man HttpWebrequest im Rahmen von Threading benutzt und probiert möglichst schnell Dateien darüber zu laden, wird die HttpWebRequest-Klasse schnell zur Spaßbremse.
Mag man Anfangs noch die Probleme an der Internetverbindung vermuten, merkt man meist spätestens nach einem Geschwindigkeitsvergleich mit wget oder Curl, dass das “Problem” bei der .NET-Implementierung liegen muss.
Im nachfolgenden Artikel möchte ich auf 3 Punkte eingehen, die euch helfen, das letzte aus der HttpWebRequests-Klasse herauszuholen.1. DefaultConnectionLimit erhöhen
Alle Instanzen der HttpWebRequest klasse richten sich nach gewissen Vorgaben des ServicepointManager. Eine der Eigenschaften des ServicepointManager ist das “DefaultConnectionLimit”. Standardmäßig ist das DefaultConnectionLimit auf 2 eingestellt, was heißt, dass nie mehr als 2 gleichzeitige Verbinden existieren können. Vor allem wenn man mittels Threading mehrere Requests gleichzeitig abfertigen will, entwickelt sich dies zur absoluten Bremse. In diesem Fall ist das DefaultConnectionLimit mit Bedacht und entsprechend der Kapazität, der zur Verfügung stehenden Verbindung, hochzusetzen.
ServicePointManager.DefaultConnectionLimit = connectionLimit;
Um den optimalen Wert zu finden, sollten gegebenenfalls Test mit unterschiedlichen Werten gemacht werden.
2. ProxyEinstellungen richtig vornehmen
Eine weitere Bremse können die Proxy-Server Einstellungen sein. Sucht man nach Problemen mit HttpWebRequest, so findet man häufiger die Problembeschreibung, dass nur die erste Abfrage sehr lange dauert und alle weiteren Abfragen relativ schnell gehen. Das liegt daran, dass die erste Abfrage nach der Erstellung einer Instanz nach Proxyeinstellungen sucht. Diese Suche nach dem System-Proxy kann gut und gerne zwischen 2-8 Sekunden in Anspruch nehmen. Hierfür gibt es zwei Lösungen.
Es wird kein Proxy benötigt
Sollte kein Proxy benötigt werden, so kann dieser explizit null gesetzt werden, sodass nicht nach dem systemweiten Standardproxy gesucht wird.
HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create("http://mywebsite.com"); req.Proxy = null;
Es wird ein Proxy benötigt
Wenn ein Proxy-Server benötigt wird und dieser bekannt ist (das sollte er dem Programmierer im Normalfall sein), so kann er manuell gesetzt werden. Auch so kann die langsame Suche nach einem Proxy umgangen werden.
string proxyUrl = "proxy.myproxy.com"; int proxyPort = 8080; WebProxy myProxy = new WebProxy(proxyUrl, proxyPort); HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create("http://mywebsite.com"); req.Proxy = myProxy;
3. Expect100Continue deaktivieren
Der letzte Tipp kann noch mal ein Paar Sekunden bringen. Genauer gesagt ca. 1/3 Sekunde pro Abfrage. Je nach Anzahl der Abfragen macht das aber schon etwas aus. In der Standardkonfiguration wird ein Continue(100) Status vor der eigentlichen Abfrage vorweg gesendet. Ist der Server bereit/willig unsere Abfrage zu verarbeiten, so bekommt der Client dies als Antwort und schickt die eigentliche Anfrage los. Das Absenden des Continue(100) und das Warten und Erhalten der Antwort darauf benötigt logischerweise Zeit.
Gehen wir davon aus, dass wir den Server kennen, können wir uns die Continue(100) Anfrage schenken und getrost deaktivieren. Hinzu kommt, dass es immer noch einige Server(-Software) gibt, die mit Continie(100) Anfragen nicht klar kommt. Wer mehr darüber wissen will, kann hier nachlesen.
ServicePointManager.Expect100Continue = false;
Das war es auch schon. Ich hoffe ihr könnt mit den Tipps etwas anfangen. Solltet ihr noch weitere Möglichkeiten kennen, Abfragen mittels HttpWebRequest zu beschleunigen, so schreibt mir einfach einen Kommentar.
Maybe in the future it’ll do even better in those areas, but for now it’s a fantastic way to organize and listen to your music and videos, and is without peer in that regard. The iPod’s strengths are its web browsing and apps.