Was könnte die Ursache für blockierte Anforderungen in IIS sein?

Was könnte die Ursache für blockierte Anforderungen in IIS sein?

Ich verwende IIS auf Windows Server 2016 mit MySQL und PHP auf zwei nahezu identischen Servern. Ich habe kürzlich eine Verlangsamung auf einem meiner beiden Server bemerkt, aber das passiert nur, wenn meine Site versucht, mehrere Instanzen eines Skripts gleichzeitig auszuführen. Sie scheinen aneinander hängen zu bleiben.

Ein perfektes Beispiel ist meine Suchseite. Wenn der Benutzer eine Suchanfrage eingibt, wird bei jedem Tastendruck (nach dem zweiten Buchstaben) eine Suche ausgeführt, solange seit dem letzten Tastendruck mindestens 200 ms Verzögerung vorliegen. Wenn Sie also schnell tippen, wird am Ende nur eine Suche ausgeführt, aber bei langsameren Tippern (die mehr als 200 ms zwischen den Tastendrücken warten) werden mehrere Aufrufe der Suchergebnisse ausgelöst. Sehen Sie sich diesen Screenshot an.

SCHLECHTER SERVER Bildbeschreibung hier eingeben

Beachten Sie alle ausstehenden Anfragen. In diesem Screenshot wurde die erste gerade erst nach 19,08 Sekunden beendet. Offensichtlich viel zu lang. Bis sie alle fertig sind, dauert es bei allen deutlich über 15 Sekunden, bis ein einfaches Ergebnisset zurückgegeben wird.

SCHLECHTER SERVER Bildbeschreibung hier eingeben

Bedenken Sie, dass diese Abfragen nur den Bruchteil einer Sekunde dauern, wenn sie in MySQL Workbench ausgeführt werden, und auch, wenn sie auf meinem anderen Server ausgeführt werden, der nicht unter diesem Problem leidet. Sehen Sie in diesem Screenshot (vom guten Server), dass genau dieselbe Suche in einer Viertelsekunde Ergebnisse liefert.

GUTER SERVER Bildbeschreibung hier eingeben

Mir scheint, dass sie (auf dem fehlerhaften Server) aus irgendeinem Grund nicht gleichzeitig ausgeführt werden können, denn wenn ich nur eine einzige Suche ausführe (indem ich schnell genug tippe, um nur eine einzige Suche auszulösen), kommt sie schnell zurück, aber wenn ich auf diese Weise mehrere ausführe, bleiben sie alle wie in einem Stau stecken. Was könnte die Ursache dafür sein?

Der nächste Screenshot zeigt das Ergebnis, wenn ich nur eine einzige Suche auf dem fehlerhaften Server auslöse. Wie Sie sehen, kommt es superschnell zurück. Das Problem tritt also nur auf, wenn mehrere gleiche Skripte gleichzeitig ausgeführt werden.

SCHLECHTER SERVER Bildbeschreibung hier eingeben

Ich habe vor Kurzem einige Änderungen an dem fehlerhaften Server vorgenommen, aber soweit ich mich erinnern kann, bestand die einzige Änderung darin, das Hochladen größerer Dateien zu ermöglichen.

  • In PHP habe ich post_max_size = 500M erhöht
  • In PHP habe ich upload_max_filesize = 500M erhöht
  • In IIS habe ich UploadReadAheadSize auf 49152000 erhöht
  • In IIS habe ich die maximal zulässige Inhaltslänge auf 300000000 erhöht

Möglicherweise habe ich noch weitere Änderungen an diesem Server vorgenommen, an die ich mich nicht erinnern kann.

VORÜBERGEHENDE LÖSUNG

Ich kann dieses Problem abmildern, indem ich bei der Suche eine längere Verzögerung zwischen den Tastenanschlägen zulasse. Das habe ich getan und sie auf 800 ms erhöht, sodass selbst langsame Tipper dieses Problem nicht bemerken. Das ist allerdings nur eine Notlösung und behebt nicht das zugrunde liegende Problem, das auch andere Bereiche meiner Site betrifft.

WAS ICH VERSUCHT HABE

Bisher habe ich bestätigt, dass meine IIS-Konfiguration, MySQL-Konfiguration (my.ini) und meine PHP-Konfiguration (php.ini) auf beiden Servern in jeder Hinsicht identisch sind (zumindest soweit es mir offensichtlich erscheint). Ich habe auch bestätigt, dass die Select-Anweisungen, die ich in dieser Suche ausführe, auf beiden Servern gleich gut funktionieren, wenn ich sie in MySQL Workbench ausführe. Dieses Problem habe ich nur in meiner Webanwendung.

Ich habe vorsichtshalber die beiden Änderungen, die ich für größere Datei-Uploads an IIS vorgenommen hatte, vorübergehend rückgängig gemacht, aber das schien keinen Unterschied zu machen.

Ich habe auch LeanSentry heruntergeladen und installiert, das mich ein- oder zweimal am Tag warnt, dass auf meiner Site blockierte Anfragen aufgetreten sind. Ich gehe davon aus, dass dies genau das ist, was ich hier sehe. Leider kann LeanSentry die Ursache des Problems nur bei ASP-Seiten ermitteln, nicht bei PHP. Es bestätigt mir also im Wesentlichen nur, dass ein Problem vorliegt, kann mir aber darüber hinaus nicht weiterhelfen.

ANDERE SYMPTOME

Ich sehe ähnliche Probleme, wenn ich mehrere Berichte gleichzeitig öffne. Wenn ich einen Bericht vollständig laden lasse, bevor ich den nächsten öffne, werden sie alle schnell geladen, aber wenn ich meine App zwinge, mehrere Berichte gleichzeitig zu öffnen, bleiben sie alle hängen.

Was könnte die Ursache für dieses Engpassproblem sein?

Antwort1

Ich denke nicht, dass es am IIS-Server liegt, hier liegt das Problem vor. Bei jeder Suche wird in Ihrem Code ein neuer Aufruf angefordert, und es sieht so aus, als ob etwas in Ihrem PHP-Skript lange dauert.

Jedes Mal, wenn Sie eine neue Anfrage senden, blockieren Sie einfach neue PHP-Instants, und wenn PHP keine Instants mehr hat, stürzt es ab.

Es ist schwer zu wissen, was Sie in Ihrer PHP-Suchdatei tun, aber ich glaube, Sie rufen einen SQL-Server oder etwas anderes zum Suchen auf. Können Sie versuchen, die Suchanfrage im Code auszukommentieren und denselben Test durchzuführen?

Momentan kann ich nur so gut raten, wie ich kann. Es hört sich an, als ob Sie eine Art regulären Ausdruck oder eine ähnliche Funktion in Ihrer SQL-Datenbank verwenden, und wenn Sie viele Zeilen haben, ist ein Aufruf extrem langsam, weshalb es oft hängt.

Aber ich schätze wiederum, dass ich das Ergebnis des Tests, den ich Ihnen verordnet habe, erst so spät erfahren werde.

Antwort2

Es stellte sich heraus, dass das HTML-Rendering das Hängenbleiben verursachte. Wenn meine Suchergebnisse lang waren, dauerte es lange, bis der Browser das gesamte HTML gerendert hatte, und währenddessen konnte er die nächste Anfrage nicht verarbeiten.

Ich habe das Problem gelöst, indem ich die Suchergebnisse auf 50 Zeilen beschränkt habe, sodass das HTML jetzt fast sofort gerendert wird und die nächste Anfrage ausgeführt werden kann. Es war also nicht IIS, der die Anfragen blockierte, sondern der Browser.

verwandte Informationen