A la hora de elegir un plan de alojamiento, es importante escoger el que mejor se adapte a las demandas de tu sitio de WordPress.

Por ejemplo, un sitio de comercio electrónico que recibe 50.000 visitantes al mes suele ser mucho más exigente en cuanto a recursos que un simple blog con la misma cantidad de tráfico.

Esto se debe simplemente al hecho de que los sitios de comercio electrónico son típicamente dinámicos por naturaleza, y requieren más recursos para consultas de PHP y bases de datos.

Ahí es donde los PHP workers entran en juego. Lee más abajo acerca de lo que son los PHP workers y cómo se utilizan para acelerar el procesamiento de las solicitudes en tu sitio.

¿Qué es un PHP worker?

En el contexto de WordPress, los PHP workers construyen páginas, procesan tareas de fondo programadas y más. Dado que los PHP workers son directamente responsables de generar páginas HTML para servir a los visitantes de tu sitio, ellos determinan cuántas peticiones simultáneas sin conexión tu sitio puede manejar en un momento dado.

Por ejemplo, digamos que tu sitio de WordPress está equipado con dos PHP workers y sin configuración de caché de página. Si cuatro solicitudes llegan a tu sitio exactamente al mismo tiempo, dos de esas solicitudes serán procesadas inmediatamente, mientras que las otras dos tendrán que esperar en la cola hasta que las dos primeras hayan terminado de ser procesadas.

Aquí en Kinsta, usamos PHP workers como una de las variables para nuestros diferentes niveles de planes. Por ejemplo, los planes de Business 1 tienen 4 PHP workers por sitio, mientras que los planes de Enterprise 4 tienen 16.

Aunque implementamos el caching a nivel de servidor, para las peticiones en las que el cache se pasa por alto o se pierde, los PHP workers se vuelven muy importantes ya que tienen que hacer el trabajo para cada petición.

Típicamente vemos muchas solicitudes no atendidas en sitios de comercio electrónico y foros comunitarios. Por lo tanto, estos sitios requerirán PHP workers adicionales para asegurar que cada solicitud sea procesada sin retrasos o tiempos muertos.

Si tu sitio está altamente optimizado o no tiene mucho código PHP (por ejemplo, un tema complejo o muchos plugins de WordPress), entonces el procesamiento de cada solicitud debería ocurrir casi instantáneamente. Incluso con 2 PHP workers y 4 solicitudes, las cuatro solicitudes se manejarían muy rápidamente.

En pocas palabras, un PHP worker es un proceso en segundo plano en un servidor que ejecuta código PHP.

¿Cómo utiliza WordPress los PHP workers?

Antes de entrar en cómo optimizar el uso de los PHP workers para WordPress, tenemos que entender cómo WordPress utiliza los PHP workers en primer lugar.

Un pedido típico en un ambiente sin cobertura es algo como esto:

  1. El servidor web (Nginx o Apache) recibe una solicitud de un visitante.
  2. Nginx pasa la petición a PHP.
  3. PHP consulta la base de datos MySQL según sea necesario y utiliza las plantillas PHP de tu tema para generar una página HTML.
  4. PHP entrega una página HTML renderizada al servidor web.
  5. La página se sirve al visitante.

En el proceso destacado anteriormente, el paso 3 es el que requiere más tiempo y recursos (CPU y RAM). Un sitio altamente optimizado con mínimas consultas a la base de datos y un código PHP eficiente pasará el tercer paso relativamente rápido.

Por el contrario, un sitio con código PHP mal escrito que hace muchas consultas innecesarias a la base de datos pasará mucho más tiempo en el paso 3, lo que significa que las solicitudes ocuparán a los PHP workers por períodos de tiempo más largos.

La relación entre los PHP workers y la CPU

Cuando se trata del rendimiento de WordPress, la relación entre los PHP workers y la CPU disponible es importante para considerar.

Si la falta de recursos de la CPU es el principal impedimento de tu sitio, el aumento del número de trabajadores de PHP no aumentará el rendimiento de tu sitio – sólo permitirá que tu sitio procese más peticiones al mismo tiempo con un rendimiento por petición más lento.

Déjame explicarte.

Imagina una boca de incendios con una sola manguera conectada a ella. Con una sola manguera conectada, el hidrante es capaz de proporcionar una presión de agua adecuada. Ahora, ¿qué pasa si conectamos diez mangueras a la boca de incendios?

La limitada presión de agua se reparte en diez mangueras, lo que significa que cada manguera individual tiene menos presión de agua para hacer el trabajo. En esta analogía, la boca de incendios es la CPU, y las mangueras son PHP workers.

Teniendo en cuenta lo anterior, debes tener cuidado si tu host te aconseja constantemente aumentar los PHP workers sin mencionar también la CPU.

Aquí en Kinsta, nuestros contenedores LXD personalizados están configurados con amplios recursos de CPU y la RAM. También usamos máquinas virtuales C2 optimizadas para computación, equipadas con las CPU más rápidas de Google Cloud para ayudar a los PHP Workers de tu sitio a correr más eficientemente. Nuestra infraestructura escalable asegura que los PHP workers de tu sitio WordPress tengan suficientes recursos de CPU para operar al máximo rendimiento.

Volvamos a la analogía de la boca de incendios por un momento.

Imagina que estás en una situación en la que necesitas apagar diez incendios con cinco mangueras. Después de conectar las cinco mangueras, te das cuenta de que la boca de incendios sigue proporcionando una presión de agua adecuada.

En esta situación, tendría sentido conectar unas cuantas mangueras más porque la presión del agua del hidrante no es el cuello de botella.

Del mismo modo, si tu sitio está funcionando mal incluso con una sobrecarga adecuada de la CPU y la RAM, es entonces cuando debería considerar el aumento del número de PHP workers como una opción para mejorar el rendimiento.

¿Cómo optimizar el uso del PHP worker de tu sitio?

Hemos explicado que los PHP workers son procesos en segundo plano que generan páginas HTML con código PHP. Ahora, la forma más obvia de reducir y optimizar el uso de los PHP workers es reducir la cantidad de recursos de CPU y PHP requeridos para cumplir con las solicitudes a tu sitio.

Así es como se hace.

1. Configura el caché para tu sitio de WordPress

El primer paso para reducir el uso de los PHP workers es configurar las capas de caché para tu sitio de WordPress. De forma predeterminada, WordPress es un CMS dinámico que satisface cada solicitud de página bajo demanda.

Para muchos sitios como blogs, revistas en línea y portafolios, el uso de PHP para generar dinámicamente páginas para cada solicitud es innecesario.

Caching de páginas

La entrada del blog que estás leyendo es el ejemplo perfecto de una página que no necesita ser generada dinámicamente. Como muchos de nuestros otros posts, el contenido de este post está diseñado para ser estático, por lo que no hay necesidad de gastar recursos de la CPU para generar páginas idénticas continuamente.

En cambio, es mejor que PHP genere la página una vez y luego la cachee. El cacheo de páginas tiene muchas ventajas obvias sobre la generación dinámica de páginas con PHP.

Por ejemplo, imagina que una entrada de un blog en tu sitio se vuelve viral y recibe 100.000 páginas vistas a las pocas horas de su publicación. Sin el almacenamiento en caché de la página, tus PHP workers probablemente se verían abrumados y tu servidor se caería.

Con el almacenamiento en caché de páginas, sólo la vista de la primera página se generaría dinámicamente. Las otras 99.999 peticiones se servirían desde tu caché de páginas, que utiliza relativamente pocos recursos de la CPU.

Hay dos maneras de configurar el caché de páginas para tu sitio de WordPress.

  1. Caching de páginas a nivel de servidor con un servidor web como Nginx.
  2. Caching de página basado en un plugin de WordPress como WP-Rocket.

Para obtener el máximo rendimiento, recomendamos utilizar el almacenamiento en caché de páginas a nivel de servidor siempre que sea posible. En Kinsta, todas nuestras páginas usan el módulo de caché FastCGI de Nginx para un rendimiento superrápido.

Si tu host no ofrece la opción de almacenamiento en caché de páginas a nivel de servidor, la siguiente mejor opción es utilizar un plugin de almacenamiento en caché de WordPress para implementar el almacenamiento en caché de páginas a nivel de aplicación.

Caching de objetos

Para las tiendas WooCommerce, los foros de la comunidad y otros sitios de WordPress que no pueden hacer uso de la caché de páginas de manera eficiente, añadir un caché de objetos persistentes como Redis delante de tu base de datos MySQL puede aumentar el rendimiento y reducir la carga de los PHP workers.

Sin un caché de objetos persistente, las consultas a la base de datos MySQL se ejecutarán para cada solicitud, incluso si el resultado es idéntico a una consulta anterior.

Por ejemplo, un sitio de foro de la comunidad que evita el caché de páginas hará consultas idénticas separadas a la base de datos para obtener datos de publicaciones con el fin de construir una página.

En el caso de los sitios de gran tráfico y con gran cantidad de bases de datos, este método de consulta de la base de datos es ineficaz porque utiliza PHP workers para generar resultados de consulta idénticos para solicitudes separadas. Ahí es donde entra Redis.

Redis almacena los resultados de las consultas de la base de datos en la RAM, lo que permite a PHP tomar los resultados de las consultas que ya han sido ejecutadas. Este método de almacenamiento en caché de objetos permite a los PHP Workers conservar los recursos de la CPU y pasar menos tiempo atendiendo una solicitud porque elimina la necesidad de realizar consultas repetitivas a la base de datos.

2. Optimiza tu código PHP

Además de configurar la caché de la página, otra estrategia que te ayudará a reducir el uso de los PHP workers es optimizar tu código PHP. En el contexto de WordPress, «optimizar el código PHP» puede significar una variedad de cosas diferentes, así que vamos a echar un vistazo más profundo.

Una de las características más queridas y odiadas de WordPress (dependiendo de a quién le preguntes) es su extensibilidad a través de plugins y fragmentos de código.

Si quieres añadir un widget de información sobre acciones a tu sitio de WordPress, hay un plugin para eso. Del mismo modo, si quieres añadir fuentes personalizadas, también hay un fragmento de código functions.php para eso.

Ampliar el núcleo de WordPress con características adicionales se ha vuelto tan fácil que a menudo nos pasamos de la raya sin pensar en el impacto potencial en el rendimiento del sitio.

Por lo tanto, la primera manera de optimizar tu código PHP es realizar una auditoría en todo el sitio para determinar qué plugins y fragmentos de código son realmente necesarios.

Elige Plugins de calidad

La mayoría de las veces, el número de plugins en tu sitio de WordPress no es tan importante como la calidad de los plugins. Si un plugin no ha sido actualizado en los últimos seis meses, te recomendamos que elijas otro que se ajuste a tu perfil.

La razón de esto es que WordPress está siendo mejorado constantemente. Si un plugin no ha sido actualizado en años, lo más probable es que su código no esté utilizando las últimas prácticas de desarrollo y seguridad de WordPress.

Por el contrario, si un plugin se actualiza constantemente cada pocas semanas, es muy probable que el desarrollador se tome en serio la calidad, lo que lo convierte en una buena opción para tu sitio de WordPress.

Usa los plugins sólo cuando sea necesario

Si quieres realizar una tarea sencilla en tu sitio como añadir JavaScript o CSS, no siempre necesitas un plugin para eso. En su lugar, puedes añadir código directamente a las plantillas PHP de tu tema o al archivo style.css con un tema hijo.

La próxima vez que estés en una situación en la que estés pensando en instalar un plugin, dedica un tiempo a mirar si es 100% necesario primero. A veces, no hay forma de evitar instalar otro plugin y eso está bien. En otras ocasiones, es posible que puedas evitar añadir código adicional si no instalas plugins innecesarios.

Elige temas ligeros

Por nuestra experiencia en la monitorización de miles de sitios de WordPress, hemos encontrado que los temas son ocasionalmente la causa de un pobre rendimiento del PHP. Para satisfacer la versatilidad de WordPress como un CMS de propósito general, algunos desarrolladores codifican temas para trabajar en una variedad de casos de uso.

A menudo, esto resulta en temas con mucho código e inflados que no utilizan el PHP y las consultas a bases de datos de manera eficiente.

Cuando se construye un sitio de WordPress, es importante elegir un tema que sea más eficaz y personalizable: GeneratePress, OceanWP y Astra son tres ejemplos.

3. Elige un host de WordPress centrado en el rendimiento

Lo creas o no, elegir el host de WordPress adecuado puede tener un gran impacto en el rendimiento de tu sitio. Dado que la eficiencia de un PHP worker está directamente correlacionada con la CPU y la RAM, alojar tu sitio en un servidor moderno con el último hardware puede ayudarle a optimizar el uso del PHP worker.

Aquí hay dos ejemplos que muestran por qué la elección de un host centrado en el rendimiento es importante para tus sitios de WordPress.

CPU de alto rendimiento

PHP utiliza recursos de la CPU para ejecutar el código. Una CPU más rápida significa una ejecución de código más rápida. En Kinsta, usamos los servidores más rápidos de Google Cloud, máquinas virtuales C2 optimizadas para computación.

Estas máquinas virtuales están equipadas con los últimos procesadores Intel Xeon capaces de operar a 3,8 GHz con un turbo de núcleo completo. En nuestras pruebas de referencia, vimos que las máquinas C2 superaban a las máquinas tradicionales N1 por 2-4x.

Almacenamiento rápido de SSD

La velocidad de E/S del disco puede tener un impacto directo en la ejecución del código y las consultas a la base de datos. Si tu base de datos se almacena en un disco mecánico lento o en un SSD basado en nube sin suficientes IOPS (operaciones de entrada/salida por segundo), tus PHP workers se verán obligados a dedicar más tiempo a satisfacer una solicitud.

Utilizamos el almacenamiento SSD de alto rendimiento de la plataforma Google Cloud para asegurarnos de que tu sitio de WordPress tenga acceso a una rápida E/S de disco.

4. Trabajar con un experto en rendimiento (opcional)

Si no estás seguro de cómo abordar un problema de rendimiento en tu sitio, te recomendamos que trabajes con un experto en rendimiento cualificado para diagnosticar el problema.

Un experto puede ayudarte a identificar cuellos de botella específicos en tu código utilizando herramientas de monitorización avanzadas como New Relic o el plugin Query Monitor de WordPress.

Al hacer zoom e inspeccionar los procesos individuales de PHP y las consultas a la base de datos, es posible identificar bloques específicos de código y sus características asociadas que están poniendo una gran carga en los PHP workers de tu sitio.

Para resumir la optimización del PHP worker, ten en cuenta los siguientes consejos.

  1. La CPU y la RAM deben ser ampliadas junto con los PHP Workers. Si el uso de la CPU está bloqueado al 100%, añadir más PHP workers no mejorará el rendimiento.
  2. Alojar tu sitio con un host centrado en el rendimiento puede resolver muchos problemas de rendimiento.
  3. El almacenamiento en caché de páginas y objetos puede reducir significativamente la carga de PHP worker.
  4. El uso de plugins y temas de calidad de WordPress puede reducir la cantidad de código innecesario en tu sitio.
  5. Si es necesario, trabaja con un experto en rendimiento para identificar y resolver problemas complejos.

Los resultados de no tener suficientes PHP workers

Para lograr un rendimiento rápido y fiable para tu sitio de WordPress, es importante asegurarse de que tienes suficientes PHP workers. Cuando los PHP workers ya están ocupados en un sitio, empiezan a formar una cola.

Una vez que has alcanzado tu límite de PHP worker, la cola comienza a expulsar peticiones antiguas que podrían resultar en errores 504 o peticiones incompletas.

Otro error común que vemos debido a la falta de PHP workers es el error 502 de la puerta de enlace. Estos son ligeramente diferentes de los errores 504 porque el error ocurre después de un timeout de 60 segundos en la cola de los PHP workers.

Estos errores no sólo presentan una mala experiencia de usuario para tus visitantes, sino que también pueden tener un impacto negativo en el SEO de tu sitio.

Un error 502 (Bad Gateway).
Un error 502 (Bad Gateway).

Hay una serie de factores diferentes que pueden causar cargas lentas de páginas o errores. Por ejemplo, si una solicitud no almacenada requiere muchos datos de la base de datos, la consulta resultante podría tardar entre 20 y 30 segundos en completarse.

En esta situación, un PHP worker estaría ocupado por lo menos medio minuto. Si tu sitio sólo tiene dos PHP Workers, sólo dos o tres de estas largas solicitudes pueden ser suficientes para empezar a causar errores.

Para resolver esto, la optimización de la base de datos MySQL y el aumento de los PHP workers si la CPU no está ya al máximo puede mejorar el rendimiento.

Estimando el número de PHP workers requeridos

Cada uno de los planes de Kinsta incluye un cierto número de PHP workers. El número incluido de trabajadores PHP se basa en las métricas de uso de recursos históricos que hemos recogido en los últimos años. En general, los sitios con contenido principalmente estático – artículos, páginas estáticas y portafolios – no requieren muchos PHP workers.

Para sitios más grandes de WordPress con funcionalidad más dinámica como el comercio electrónico o los foros de discusión, hemos encontrado que 4 PHP workers son un buen punto de partida. Sin embargo, esto puede variar por sitio ya que cada uno tendrá su propio conjunto de temas, plugins, consultas a la base de datos, y la proporción de caché a caché.

En algunos casos, se pueden necesitar más PHP workers para un rendimiento rápido y fiable. Si no estás seguro de cuántos PHP workers necesita tu sitio en Kinsta, nuestros equipos de ventas y soporte pueden ayudarte a averiguarlo.

Tabla de límites de trabajadores PHP

La tabla de límites de PHP workers en MyKinsta analytics te permite ver cuántas veces el motor de PHP informó haber alcanzado el número máximo de trabajadores asignados en su registro de errores. Este gráfico puede ayudarte a medir si las optimizaciones de rendimiento están afectando o no al uso de su PHP worker.

Bypass de cache superior.
Bypass de cache superior.

Por ejemplo, si cambiara la versión de PHP de tu sitio de 5.6 a 7.4, probablemente vería una disminución en los límites de PHP workers porque PHP 7.4 es mucho más rápido que 5.6.

Del mismo modo, si trabajaste con un experto en rendimiento para arreglar consultas largas de la base de datos y cambiar a un tema más ligero, puedes utilizar la tabla de límites de PHP workers para ver las diferencias antes y después de las optimizaciones.

Cuadro de análisis de la caché

También puedes usar el informe de análisis de la caché en MyKinsta para determinar el número de aciertos, desvíos, fallos y caducidades de la caché. Estos datos pueden ser especialmente útiles para optimizar el uso de los PHP Workers en tu sitio.

Bypass de caché con cadenas de consulta

Por defecto, las URLs con cadenas de consulta como https://kinstalife.com/?query=123 evitan la caché de páginas. En algunos casos, las cadenas de consulta pueden resultar en un gran aumento del uso innecesario de PHP y CPU.

Por ejemplo, si visitas un enlace de Facebook, a menudo verás la cadena de consulta ?fbclid= al final de la URL. Del mismo modo, puede ver los parámetros de seguimiento UTM después de hacer clic en un enlace en un boletín de correo electrónico.

Una URL con una cadena de consulta (?querystring=123).
Una URL con una cadena de consulta (?querystring=123).

Si una publicación en su sitio se vuelve viral, y se accede constantemente con una cadena de consulta, podrá identificar la URL específica con el informe de análisis de la caché.

Con esa información clave, puedes contactar con nuestro equipo de soporte para forzar la caché de esa URL específica para reducir la carga de tus trabajadores PHP.

Identificar los plugins de gran capacidad de recursos

En algunos casos, el gráfico de análisis de la memoria caché también se puede utilizar para identificar los complementos y procesos con gran cantidad de recursos.

Por ejemplo, si ves que la URL del bypass de la caché superior apunta a un archivo dentro del directorio de un plugin específico, hay una buena posibilidad de que el plugin sea responsable del alto uso de los PHP workers.

Si ves muchas solicitudes relacionadas con los plugins en la lista de derivación de la caché, puedes trabajar con un desarrollador para solucionar el problema o cambiar a un plugin que utilice menos recursos.

Resumen

El objetivo de mantener un sitio de WordPress rápido es maximizar la eficiencia del backend. Cuando los PHP workers se utilizan adecuadamente encontrando un equilibrio entre el número de trabajadores, el uso de la CPU y la optimización del código, WordPress puede ser un CMS extremadamente eficiente.

Considera utilizar la función de minificación de código si eres cliente de Kinsta. Esta función está integrada directamente en el panel de control de MyKinsta y permite a los clientes activar fácilmente la minificación automática de CSS y JavaScript con un simple clic.

Si tienes alguna pregunta sobre cuántos PHP workers puedes necesitar, o crees que puedes estar viendo errores debido a la falta de PHP workers, por favor, abre un ticket con nuestro equipo de soporte para obtener ayuda.

Ahora te toca a ti: ¿Qué estrategias de optimización utilizas para que tu sitio de WordPress funcione sin problemas? Házanoslo saber en los comentarios!