Ich habe Probleme mit der Arbeit mit WEB Api. Auf meinem realen / Produktionscode werde ich einen SOAP-WS-Aufruf machen, in diesem Beispiel werde ich einfach schlafen. Ich habe 400 Clients, die Anfragen an die Web-API senden.
Ich denke, es ist ein Problem mit Web-API, denn wenn ich den Prozess 5 öffne, kann ich mehr Anfragen bearbeiten, als wenn ich nur mit einem Prozess arbeite.
Meine asynchrone Testversion des Controllers sieht so aus
%Vor%Die Sync-Version sieht so aus
%Vor%Mein Clientcode für diesen Test sieht so aus (er ist so konfiguriert, dass er nach 30 Sekunden abläuft)
%Vor%Ich konnte es hier nicht schön darstellen, aber die Tabelle mit den Ergebnissen ist unter github verfügbar
Die CPU-, Speicher- und Festplatten-IO ist niedrig. Es gibt immer mindestens 800 verfügbare Threads (sowohl Worker- als auch Io-Threads)
%Vor%Ich habe das DefaultConnectionLimit
konfiguriert %Vor%Meine Frage ist, warum es eine Warteschlange gibt, um diese Anfrage zu beantworten? Bei jedem Test begann ich mit einer Antwortzeit fast genau wie die Server Thread.Sleep () Zeit, aber die Antworten werden langsamer, wenn neue Anfragen eintreffen.
Irgendwelche Tipps, wie ich herausfinden kann, wo der Bootleneck ist?
Es ist eine .net 4.0-Lösung, die die self-host-Option verwendet.
Bearbeiten: Ich habe auch mit .net 4.5 und Web API 2.0 getestet, und das gleiche Verhalten. Erste Anfragen haben die Antwort fast sobald der Schlaf abgelaufen ist, später dauert es bis zu 4x die Schlafzeit um eine Antwort zu erhalten.
Edit2: Giste der Web-API-Implementierung und gist der web-api2-implementierung
Edit3: Die MakeHttpPost-Methode erstellt einen neuen WebApiClient
Bearbeiten4:
Wenn ich das ändere
%Vor%zu
%Vor%in der .net Version 4.5, kann es alle Anfragen wie erwartet verarbeiten. Ich denke also nicht, dass etwas mit einem Netzwerkproblem zu tun hat. Da Thread.Sleep () den Thread und Task.Delay nicht blockiert, sieht es so aus, als gäbe es ein Problem mit Webapi, um mehr Threads zu verbrauchen. Aber es gibt verfügbare Threads im Threadpool ...
Bearbeiten 5: Wenn ich 5 Server öffne und die Anzahl der Clients verdopple, kann der Server auf alle Anfragen antworten. Es sieht also so aus, als wäre es kein Problem mit der Anzahl der Anfragen an einen Server, da ich diese Lösung skalieren kann, indem eine große Menge an Prozessen in verschiedenen Ports ausgeführt wird. Es ist mehr ein Problem mit der Anzahl der Anfragen an den gleichen Prozess.
Führen Sie Netstat auf dem Server aus, der das Problem hat, suchen Sie nach Time-Waits, Fin-Wait-1, Fin-Wait-2 und RST-Wait, RST-Wait2. Dies sind halbgebackene Sitzungen, wobei der Stapel darauf wartet, dass die andere Seite aufräumt ..... ODER ..... die andere Seite hat ein Paket gesendet, aber die lokale Maschine konnte sie noch nicht verarbeiten, abhängig von den Stapeln "Verfügbarkeit, um den Job zu machen.
Der Kicker ist, dass sogar Sessions, die Established zeigen, Probleme haben könnten, weil die Auszeit noch nicht gefeuert wurde.
Die oben beschriebenen Symptome erinnern an Netzwerk- oder TCP / IP-Stapelüberlastung. Ein sehr ähnliches Verhalten wird beobachtet, wenn Router überlastet werden.
Tags und Links asp.net-web-api .net c# performance