Ejecutando WordPress en IIS 7 (Windows Server 2008) con WP-SuperCache según Guía de IIS.net.
Estaba funcionando muy bien, pero recientemente cambiamos los permisos en algunas carpetas y la contraseña del administrador y estamos obteniendo grandes picos en el uso de nuestra CPU como resultado de los procesos PHP-cgi.exe.
Esto me lleva a creer que no se está almacenando en caché, sin embargo, las páginas en sí tienen los comentarios “En caché con WP-SuperCache” en la parte inferior, y el almacenamiento en caché parece funcionar correctamente.
¿Qué más podría ser el problema aquí?
Creo que pude haber encontrado una solución o al menos una solución alternativa a este problema, al menos parece estar funcionando para mí de manera confiable.
Intente establecer la configuración de Max Instances, en IIS Server –> FastCGI Settings, en 1.
Me pareció que solo ciertas solicitudes estaban causando que un proceso php-cgi.exe se volviera deshonesto y acaparara la CPU, generalmente al actualizar una publicación. Al leer otras publicaciones sobre este problema, una de ellas mencionó la configuración de instancias máximas y que está configurada de forma predeterminada en 0 o automática. Me preguntaba si esto podría no tener un buen efecto cuando las cosas no son como deberían ser. Supongo (pero este no es mi campo de especialización) si una(s) determinada(s) solicitud(es) está(n) causando que el proceso se bloquee, por lo que FastCGI simplemente crea otra, mientras deja la primera en su lugar. De alguna manera, parece que solo tener una única instancia permite que PHP pase del bloqueo y la CPU permanece bajo control.
Para servidores con altos niveles de solicitudes, configurar FastCGI en una sola instancia puede no ser lo ideal, pero ciertamente supera los retrasos que tenía antes. Usado en combinación con WP-SuperCache y WinCache, las cosas parecen funcionar muy bien ahora.
-
Estoy votando a favor de esta respuesta porque, si bien no resuelve la raíz del problema, gana tiempo para resolver la raíz.
– Brandt Solovij
24 de abril de 2014 a las 18:16
Al mirar esa tarea, parece que el administrador le falta el caché en cada solicitud. Además, ese artículo data de 2008, por lo que es difícil decir si las instrucciones tal como están escritas seguirán funcionando. Algo con WP-SuperCache podría haber cambiado.
Recomendaría usar W3 Total Cache. He realizado pruebas exhaustivas con él en Windows Server 2008 e IIS 7 y funciona muy bien. También es compatible y aprovecha la extensión WinCache para PHP. También tiene otras características excelentes si está interesado, minificación, compatibilidad con CDN, etc. Es un complemento de rendimiento realmente excelente para WordPress. Puede obtener el complemento aquí, http://wordpress.org/extend/plugins/w3-total-cache/
algunas otras cosas para revisar…
¿De qué tamaño es el grupo de aplicaciones? (¿# de procesos?) Asegúrese de estar usando PHP 5.3. Asegúrese de estar usando WinCache. Asegúrese de establecer MaxInstanceRequests en algo menor que PHP_FCGI_MAX_REQUESTS. Definitivamente no permita que PHP maneje el reciclaje del grupo de aplicaciones. El valor predeterminado es 10 000 solicitudes. Si ve estos resultados durante una prueba de carga, esta podría ser la causa. Aumente MaxInstanceRequests y manténgalo uno menos que PHP_FCGI_MAX_REQUESTS.
Espero que ayude.
¿Puede agregar información adicional como registros, tiempos de procesamiento de páginas, si tiene habilitado xdebug, etc.? Por un lado, WordPress usa mucha memoria (6MB+). Dos, los complementos de wordpress usan mucha memoria (¿ha instalado algo adicional últimamente?). Tres, el servidor de Windows usa mucha memoria en comparación con una caja de Debian que ejecuta nginx (que solo tiene 40 MB).
– Xeoncross
14 de febrero de 2012 a las 21:13