WordPress en IIS 7 php-cgi acaparando la CPU

Question

Ejecución de WordPress en IIS 7 (Windows Server 2008) con WP-SuperCache según IIS.net's guide.

estaba funcionando muy bien, pero recientemente hemos cambiado los permisos en algunas carpetas y la contraseña de 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 es el almacenamiento en caché sin embargo, las páginas tienen por sí mismos "en caché con WP-SuperCache" comentarios en la parte inferior, y el almacenamiento en caché parece estar funcionando correctamente.

¿Qué otra cosa podría ser el problema aquí?

Answer 1

Al observar esa tarea, parece que el administrador falta la memoria caché en cada solicitud. Además, ese artículo data de 2008, por lo que es difícil decir si las instrucciones escritas aún funcionarían. Algo con WP-SuperCache podría haber cambiado.

Recomendaría usar W3 Total Cache. He hecho extensas pruebas con Windows Server 2008 e IIS 7 y funciona muy bien. También es compatible y aprovecha la extensión de WinCache para PHP. Tiene algunas otras características excelentes también si le interesa, la minificación, la compatibilidad CDN, etc. Es un plugin de rendimiento realmente genial para WordPress. Puede obtener el plugin aquí, http://wordpress.org/extend/plugins/w3-total-cache/

algunas otras cosas para comprobar ...

¿De qué tamaño es el grupo de aplicación? (¿Número de procesos?) Asegúrate de estar usando PHP 5.3. Asegúrate de estar usando WinCache. Asegúrese de establecer MaxInstanceRequests en algo menos que PHP_FCGI_MAX_REQUESTS. Definitivamente no permita que PHP maneje el reciclaje del grupo de aplicaciones. El valor predeterminado es 10K solicitudes. Si está viendo estos resultados durante una prueba de carga, esta podría ser la causa. Aumente MaxInstanceRequests y consérvelo menos de PHP_FCGI_MAX_REQUESTS.

Espero que ayude.

Answer 2

Creo que puedo haber encontrado una solución o al menos una ronda de trabajo para este problema, al menos parece funcionar para mí de manera confiable.

Pruebe a establecer las instancias máx Valor, bajo IIS del servidor -> Configuración FastCGI, a 1.

Me parecía que sólo ciertas peticiones estaban causando un proceso php-cgi.exe para ir pícaro y acaparar la CPU, generalmente al actualizar una publicación. Al leer otras publicaciones sobre este tema, una de ellas mencionó la configuración de instancias máximas y está configurada como 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. Estoy adivinando (pero este no es mi campo de especialización) si cierta (s) solicitud (es) están causando que el proceso se bloquee, por lo que FastCGI simplemente crea otro, mientras deja el primero en su lugar. De alguna manera, parece que tener solo una instancia permite que PHP se mueva desde el bloqueo y la CPU permanezca bajo control.

Para servidores con altos niveles de solicitudes, configurar FastCGI en una sola instancia puede no ser ideal, pero sin duda supera las demoras que recibía antes. Usado en combinación con WP-SuperCache y WinCache, las cosas parecen estar muy bien ahora.