Ausführen von WordPress auf IIS 7 (Windows Server 2008) mit WP-SuperCache gem IIS.net-Leitfaden.
Läuft großartig, aber kürzlich haben wir die Berechtigungen für einige Ordner und das Administratorkennwort geändert und wir bekommen aufgrund der PHP-cgi.exe-Prozesse enorme Spitzen in unserer CPU-Auslastung.
Dies lässt mich glauben, dass es sich nicht um ein Caching handelt, aber die Seiten selbst haben unten die Kommentare „Cached with WP-SuperCache“, und das Caching scheint korrekt zu funktionieren.
Was könnte hier noch in Frage kommen?
Können Sie zusätzliche Informationen wie Protokolle, Seitenrenderzeiten, ob Sie xdebug aktiviert haben usw. hinzufügen? Zum einen verbraucht WordPress viel Speicher (6MB+). Zweitens verbrauchen WordPress-Plugins viel Speicher (in letzter Zeit etwas extra installiert?). Drittens verbraucht der Windows-Server viel Speicher im Vergleich zu einer Debian-Box, auf der nginx ausgeführt wird (die nur 40 MB groß ist).
– Xeoncross
14. Februar 2012 um 21:13 Uhr
Ich glaube, ich habe vielleicht eine Lösung oder zumindest eine Problemumgehung für dieses Problem gefunden, zumindest scheint es bei mir zuverlässig zu funktionieren.
Versuchen Sie, die Einstellung Max. Instanzen unter IIS-Server –> FastCGI-Einstellungen auf 1 festzulegen.
Es schien mir, dass nur bestimmte Anfragen dazu führten, dass ein php-cgi.exe-Prozess abtrünnig wurde und die CPU in Beschlag nahm, normalerweise beim Aktualisieren eines Beitrags. Beim Lesen anderer Beiträge zu diesem Problem erwähnte einer von ihnen die Einstellung „Max. Instanzen“ und dass sie standardmäßig auf 0 oder automatisch eingestellt ist. Ich fragte mich, ob das nicht eine gute Wirkung haben könnte, wenn die Dinge nicht so sind, wie sie sein sollten. Ich vermute (aber das ist nicht ganz mein Fachgebiet), wenn eine bestimmte Anfrage (n) dazu führt, dass der Prozess blockiert, also erstellt FastCGI einfach eine andere, während die erste an Ort und Stelle bleibt. Irgendwie scheint es, als ob PHP nur mit einer einzigen Instanz aus dem Lock-up herauskommen kann und die CPU unter Kontrolle bleibt.
Für Server mit vielen Anfragen ist es vielleicht nicht ideal, FastCGI auf nur eine einzige Instanz zu setzen, aber es übertrifft sicherlich die Verzögerungen, die ich zuvor hatte. In Kombination mit WP-SuperCache und WinCache scheint es jetzt gut zu laufen.
Ich stimme dieser Antwort positiv zu, da sie zwar nicht die Wurzel des Problems löst, aber Zeit verschafft, um die Wurzel zu beseitigen.
– Brandt Solowij
24. April 2014 um 18:16 Uhr
Wenn man sich diesen Task-Mgr ansieht, sieht es so aus, als würde der Cache bei jeder Anfrage fehlen. Außerdem datiert dieser Artikel aus dem Jahr 2008, so dass es schwer zu sagen ist, ob die Anweisungen in der geschriebenen Form noch funktionieren würden. Etwas mit WP-SuperCache könnte sich geändert haben.
Ich würde die Verwendung von W3 Total Cache empfehlen. Ich habe umfangreiche Tests damit unter Windows Server 2008 und IIS 7 durchgeführt und es funktioniert hervorragend. Es ist auch kompatibel mit und nutzt die WinCache-Erweiterung für PHP. Hat auch einige andere großartige Funktionen, wenn Sie interessiert sind, Minimierung, CDN-Unterstützung usw. Es ist ein wirklich großartiges Leistungs-Plugin für WordPress. Sie können das Plugin hier herunterladen, http://wordpress.org/extend/plugins/w3-total-cache/
einige andere Dinge zu überprüfen …
Wie groß ist der App-Pool? (Anzahl der Prozesse?) Stellen Sie sicher, dass Sie PHP 5.3 verwenden. Stellen Sie sicher, dass Sie WinCache verwenden. Stellen Sie sicher, dass Sie MaxInstanceRequests auf etwas weniger als PHP_FCGI_MAX_REQUESTS setzen. Erlauben Sie PHP definitiv nicht, das Recycling des App-Pools zu handhaben. Der Standardwert ist 10.000 Anfragen. Wenn Sie diese Ergebnisse während eines Belastungstests sehen, könnte dies die Ursache sein. Erhöhen Sie MaxInstanceRequests und halten Sie es um eins kleiner als PHP_FCGI_MAX_REQUESTS.
Ich hoffe, das hilft.
13824600cookie-checkWordPress auf IIS 7 php-cgi belastet die CPUyes
Können Sie zusätzliche Informationen wie Protokolle, Seitenrenderzeiten, ob Sie xdebug aktiviert haben usw. hinzufügen? Zum einen verbraucht WordPress viel Speicher (6MB+). Zweitens verbrauchen WordPress-Plugins viel Speicher (in letzter Zeit etwas extra installiert?). Drittens verbraucht der Windows-Server viel Speicher im Vergleich zu einer Debian-Box, auf der nginx ausgeführt wird (die nur 40 MB groß ist).
– Xeoncross
14. Februar 2012 um 21:13 Uhr