IIS 8 Performance - Verbindungen/Threads pro Client

[Ben Carter]

Hallo allerseits!

Ich habe eine Frage zum IIS. Ich hab den Thread mal hier aufgemacht, auch wenn es vermutlich genauso gut unter Windows und Software passt. Sollte es nicht recht sein, einfach verschieben.

Und zwar läuft bei einem Kunden eine Websoftware auf Basis von IIS 8 mit PHP 7. Das ganze ist auch ordentlich schnell, doch es kommt immer wieder aufgrund von asynchronen Requests der Software zu starken Verzögerungen. Dabei habe ich festgestellt, dass es nicht einfach nur länger dauert, weil halt viel passiert (genaugenommen passiert nämlich nicht einmal sonderlich viel), sondern dass aufgrund der asynchronen Abfragen wohl irgend ein Limit überschritten wird. Vielleicht die maximal erlaubten Verbindungen pro Client oder Threads pro Client. Hab dann auch ein wenig gesucht und das gefunden:

Tune the MaxPoolThreads registry entry
This setting specifies the number of pool threads to create per processor. Pool threads watch the network for requests and process incoming requests. The MaxPoolThreads count does not include threads that are consumed by ISAPI applications. Generally, you should not create more than 20 threads per processor. MaxPoolThreads is a REG_DWORD registry entry located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ with a default value of 4.
https://docs.microsoft.com/en-us/biztalk/technical-guides/optimizing-iis-performance

Nur gibt es diesen Eintrag dort gar nicht. Die IIS Konfiguration dürfte ziemlich Out of the box sein. Bisher habe ich nur die "Maximale Anzahl von Arbeitsprozessen" von 1 auf 2 für den Anwendungspool erhöht.

Wisst ihr, welche Konfiguration eventuell noch daran schuld sein könnte?

Eigentlich sollte sich ja ein SA darum kümmern, aber aus Gründen ist das jetzt auf meinem Tisch gelandet und es gibt gerade niemanden greifbar, der sich darum kümmern kann.

Danke,
lg Ben

[Gast]

Warum um himmelswillen verwendet man den IIS für eine PHP Anwendung? Hostet das Ding doch einfach auf einem ordentlichen Linux mit Apache+mod_php oder nginx+php-fpm.

[Ben Carter]

Weil die Anwendung einen IIS voraussetzt.

[][immy]

Es ist keine gute Idee im IIS selbst threads zu erzeugen die vom Threadpool stammen. Z.B. wenn diese vom Threadpool kommen, beschränkst du den IIS relativ flott. Wenn dann muss man eigene Threads bauen welche nicht aus dem Threadpool stammen. Wenn du etwas asynchron machst und den Anfragethread warten lässt, belastest du ebenfalls den Threadpool.

[Ben Carter]

Ich habe darauf leider gar keinen Einfluss. Wird die Anwendung im Browser geöffnet, ruft sie weitere Informationen nachträglich per XMLHttpRequest (über jQuery) auf. Es gibt mehr oder weniger Ordner und die Anzeige der Anzahl der Elemente im Ordner wird asynchron geladen. Da da ein komplexes Rechtesystem dahintersteht, dauert die Anfrage durchaus, was auch der eigentliche Grund ist, dass es asynchron läuft.

Solange die Anzahl der Ordner überschaubar ist, ist das durchaus in Ordnung. Gibt es aber viele Ordner und mache ich einen Eintrag auf, so scheint es so, als würden die noch laufenden, asynchronen Anfragen eben die neue Anfrage in eine Warteschlange setzen. Warte ich, bis alles geladen ist, geht der Eintrag augenblicklich auf. Da aber das Wechseln des Ordners quasi erneut ein Refresh aller Anzeigen auslöst, muss man immer nach dem Wechseln erst mal 10-30 Sekunden warten. Reine Prozessorzeit dürfte aber nicht so das Problem sein, die Elementzahlen belasten eher den SQL-Server und somit kam ich auf den Trichter, dass eben die max. Anzahl an Verbindungen irgendwie begrenzt ist.

Auf das Verhalten selbst habe ich leider absolut keinen Einfluss. Ich kann nur an der IIS und PHP Config herumschrauben.

lg Ben

[Demirug]

Testest du mit einer Workstation oder Server Version von Windows? Die Workstation Version hat nämlich limitierungen was die Anzahl der Verbindungen zu einem Port angeht. Ich bin da auch schon einmal reingefallen.

Ich kenne mich jetzt nicht mit der PHP Integration im IIS aus. Aber bei ASP und WPF kann man über die Konfiguration die maximale Anzahl der gleichzeitig aktiven Calls konfigurieren. Abhängig von der IIS Version waren die Defaults diese Werte teilweise sehr klein.

Ansonsten hat der IIS eine Menge Performancecounter die dir vielleicht weiter helfen können das Problem einzugrenzen.

Fehlt btw ein Wert in der Registry der aber dokumentiert ist wird der Default Wert genommen. Das wird gemacht damit man bei Versionänderungen auch die Defaults ändern kann.

Ich weiß jetzt auch nicht wie die Client/Server-Seite deiner SQL Abfragen aussehen. Es könnte aber durchaus sein das es auch dort irgendwo ein Limit gibt wie viele gleichzeitige Calls pro Client (was in dem Fall ja dann dein Webserver ist) zulässig sind.

[Ben Carter]

Windows Server 2012R2. Alles was in Richtung SQL geht limitiert nicht, das konnte ich bereits testen, da ich mich da zumindest etwas mehr auskenne. :)

Ich kenne mich jetzt nicht mit der PHP Integration im IIS aus. Aber bei ASP und WPF kann man über die Konfiguration die maximale Anzahl der gleichzeitig aktiven Calls konfigurieren. Abhängig von der IIS Version waren die Defaults diese Werte teilweise sehr klein.
Ich werde mal in diese Richtung weitersuchen, danke!

lg Ben

[][immy]

Achso, eine Sache noch. Ein Browser kann mit http 1.1 auch maximal nur 6-12 Verbindungen gleichzeitig, zu einer Domain öffnen (der IE liegt hier sogar noch vorn, bei Chrome und Firefox sind es glaube ich 6-8). Das kannst du nur umgehen indem du entweder andere subdomains verwendest (z.B. JavaScript und Bilder nicht über die gleiche Domain ziehen) oder indem du auf HTTP 2 setzt.
Ansonsten müsstest du zusehen, die Calls irgendwie zu bündeln. Dann hättest du auch gleichzeitig weniger Overhead aufgrund der ganzen Calls und Auswertungen. HTTP2 ist die angenehmere Methode, hat aber einige zwingende Voraussetzungen (z.B. auf NTLM, was im intranet schon mal praktisch ist muss man verzichten). Hier wird allerdings einiges an Overhead eingespart, wodurch sogar HTTPs Calls schneller verarbeitet werden können als mit HTTP 1.1 HTTP Calls.

[Ben Carter]

Danke, das ist tatsächlich die Ursache des Problems.

Ich danke euch beiden für die Hilfe! Jetzt muss der Entwickler des Frameworks ran. :)

lg Ben