PHP

Workers PHP

Los workers PHP procesan el código PHP de un sitio. Esto incluye construir páginas, procesar tareas en segundo plano, consultar la base de datos, etc.

Puedes pensar en los workers PHP como en los empleados de una tienda. Cada trabajador sólo puede atender una petición a la vez. Si hay más clientes que trabajadores, esos clientes (procesos) tienen que hacer cola y esperar a que el siguiente trabajador disponible atienda su solicitud.

Los workers PHP entran realmente en juego cuando un sitio no almacena o no puede almacenar en caché la mayor parte de su contenido. Cuanto más dinámico sea un sitio web, más workers PHP necesitará. El contenido almacenado en caché no requiere workers PHP; en realidad sólo se necesitan cuando el sitio requiere consultar la base de datos para obtener o cambiar información.

Cuando se trata del rendimiento de WordPress, más workers PHP no significan automáticamente un mejor rendimiento; hay una serie de factores que debes tener en cuenta:

• Almacenamiento en caché: Un almacenamiento en caché eficaz puede reducir la carga de trabajo de los workers PHP al servir contenido almacenado en caché en lugar de generarlo dinámicamente para cada petición. Esto puede mejorar significativamente el rendimiento, especialmente para los recursos a los que se accede con frecuencia.
• El hardware: Los recursos de hardware disponibles en el servidor, como la CPU, la memoria (RAM) y la velocidad del disco, influyen directamente en el rendimiento de los workers PHP. Unos recursos insuficientes pueden provocar tiempos de procesamiento más lentos y un rendimiento degradado.
• Configuración del Servidor Web: La configuración del servidor web y su interacción con PHP pueden influir en el rendimiento del worker.
• Velocidad de la base de datos: Las aplicaciones PHP recuperan con frecuencia datos de bases de datos MySQL para renderizar contenidos dinámicos. La velocidad a la que se recuperan los datos está influida por aspectos como la organización de la base de datos, la optimización de las consultas y el rendimiento del servidor de la base de datos. Esto influye directamente en el funcionamiento de las aplicaciones PHP.
• Versión de PHP: Las nuevas versiones de PHP a menudo pueden dar lugar a un mejor rendimiento del worker PHP debido a mejoras en el rendimiento, correcciones de errores y actualizaciones de seguridad.

En Kinsta, valoramos la importancia del rendimiento de tu sitio web. Por eso hemos implementado varias tecnologías destinadas a maximizar el rendimiento PHP y minimizar las peticiones PHP:

• Ofrecemos caché de páginas tanto a nivel de CDN como de servidor, con reglas personalizables para garantizar la máxima eficacia del caché.
• Utilizamos servidores premium en GCP (máquinas virtuales C2 y C3D) equipados con las CPU más rápidas de Google Cloud para ayudar a que los workers PHP de tu sitio funcionen de forma más eficiente.
• Nuestra infraestructura escalable garantiza que los workers PHP de tu sitio de WordPress tengan suficientes recursos de CPU para funcionar al máximo rendimiento.
• Utilizamos una infraestructura de red de primera calidad en Google Cloud Platform (GCP) para minimizar la latencia. Al aprovechar la red premium de GCP, reducimos significativamente el tiempo que tardan los datos en viajar entre los distintos componentes de nuestra infraestructura, incluidos el servidor MySQL y los servidores web.
• Proporcionamos un servidor MySQL altamente optimizado alojado localmente para reducir la latencia de la red y mejorar la velocidad de recuperación y procesamiento de los datos.
• En el servidor MySQL, disponemos de buffers InnoDB para ayudar a mejorar el rendimiento de la base de datos reduciendo las operaciones I/O del disco. Se puede acceder a los datos más rápidamente desde la memoria que desde el disco, lo que aumenta la eficacia de las operaciones de lectura y escritura y mejora el rendimiento general de la base de datos MySQL.
• Nos aseguramos de que siempre esté disponible la última versión de PHP para incorporar cualquier mejora de rendimiento.

Workers PHP vs. Límite de memoria PHP

El número de workers PHP no debe confundirse con el límite de memoria de PHP. Los workers PHP son procesos PHP individuales que gestionan las peticiones web entrantes, mientras que el límite de memoria PHP especifica la cantidad máxima de memoria (RAM) que un único script PHP puede utilizar durante su ejecución.

Los workers PHP gestionan la concurrencia procesando múltiples peticiones simultáneamente, mientras que el límite de memoria PHP gestiona la asignación de recursos restringiendo el uso de memoria de los scripts individuales. Esto evita que un único script utilice toda la memoria disponible del servidor.

Los límites de memoria PHP son importantes para los scripts que requieren mucha memoria, como los que realizan grandes consultas a bases de datos, manejan grandes cargas de archivos o ejecutan cálculos complejos. Si encuentras errores de límite de memoria en tu sitio, aumentar el número de workers PHP no resolverá este problema. En su lugar, debes comprobar tu límite de memoria y, si es necesario, aumentarlo o adquirir un add-on de límite de memoria.

WordPress y los workers PHP

Una petición no almacenada en caché en un sitio de WordPress suele ser algo así:

1. Un visitante visita una página o realiza una acción en una página (por ejemplo, añadir algo a un carrito, enviar un formulario, etc.).
2. El servidor web (en Kinsta es Nginx) recibe esa petición.
3. Nginx pasa la solicitud a PHP.
4. PHP consulta la base de datos MySQL y obtiene la información que necesita o realiza las actualizaciones necesarias.
5. A continuación, PHP utiliza los archivos PHP de tu tema (y los archivos de cualquier plugin, si procede) para generar una página HTML.
6. PHP devuelve la página HTML generada al servidor web.
7. La página se sirve al visitante.

En el proceso descrito anteriormente, el paso 4 es el que consume más tiempo y recursos (CPU y RAM). Un sitio bien optimizado con código PHP y consultas a la base de datos eficientes procesará ese paso con bastante rapidez.

Por otro lado, un código PHP mal escrito o no optimizado y/o muchas consultas ineficaces a la base de datos tardarán mucho más en procesar el Paso 4. Las peticiones que tardan más en procesarse monopolizan a los workers PHP durante más tiempo.

Estimación del número de workers PHP necesarios

El número de workers que necesita un sitio depende de varios factores, como: lo dinámico que sea el sitio, lo optimizado que esté el código del sitio (la rapidez con la que se pueden procesar las peticiones) y el tipo de tráfico que reciba el sitio. Un sitio optimizado gestiona las peticiones rápidamente, liberando workers PHP para la siguiente petición de la cola.

Los sitios dinámicos, como las tiendas de comercio electrónico, los foros, los sitios de aprendizaje y los sitios de membresía, normalmente necesitarán más workers PHP que los sitios más estáticos, de tipo catálogo. Además, cuanto más activo sea un sitio, más workers PHP necesitará.

Planes Kinsta y workers PHP

La siguiente tabla muestra cuántos PHP workers incluye cada plan de Kinsta:

También ofrecemos planes personalizados en los que puedes indicar cuántos workers PHP necesitas. Para más información, ponte en contacto con nuestro equipo de ventas.

Workers PHP, CPU y RAM

Al añadir workers PHP, hay que tener en cuenta los recursos de CPU y RAM. Si aumentas los workers PHP, pero el servidor necesita más CPU y RAM para soportar esos workers, se creará un cuello de botella porque las peticiones no se gestionarán con eficacia.

En Kinsta, nuestros contenedores LXD personalizados están configurados con abundantes recursos de CPU y RAM. Además, al utilizar máquinas virtuales C2 y C3D optimizadas computacionalmente y equipadas con las CPU más rápidas de Google Cloud, ayudamos a que los workers PHP de tu sitio web funcionen de forma más eficiente. Nuestra infraestructura escalable garantiza que los workers PHP de tu sitio de WordPress tengan suficientes recursos de CPU para funcionar al máximo rendimiento.

Identificar problemas de rendimiento relacionados con los workers PHP

Si se acumulan demasiadas peticiones en la cola debido a una gran afluencia de peticiones, procesos de larga duración o una combinación de ambos, el sitio puede experimentar problemas de rendimiento que pueden dar lugar a errores 502 o 504.

Utilizar herramientas como la herramienta APM de Kinsta y el plugin Query Monitor puede ayudarte a identificar problemas de rendimiento y consultas lentas. También recomendamos trabajar con un experto cualificado en rendimiento para diagnosticar los problemas.

Límite de workers PHP

Puedes acceder al gráfico de límite de workers PHP en MyKinsta > Sitios WordPress > nombre del sitio > Analíticas > Rendimiento > Límite worker PHP. Si un worker PHP no tiene nada que hacer durante 10 segundos continuos, el proceso worker PHP terminará automáticamente. En cuanto se vuelva a necesitar, el proceso worker se recreará instantáneamente. Este gráfico te muestra cuántas veces se ha alcanzado el número máximo de workers asignados en tu sitio.

Por ejemplo, si tienes un plan Business 1, éste permite un máximo de 4 procesos worker PHP. Si se están utilizando 3 workers PHP y se realiza otra petición a tu sitio que requiere un worker PHP, cuando se crea el worker PHP, se alcanza el número máximo de 4 workers PHP y se registra como un incidente en el que se alcanza el límite de workers PHP.

Esto sólo puede darte una imagen parcial de tu actividad de workers PHP, ya que sólo registra el número de veces que se alcanza el límite de workers PHP y no cuánto tiempo estuvieron en uso todos los workers PHP.

Por ejemplo, si tu sitio experimenta un aumento de tráfico, puede que todos los workers PHP permanezcan constantemente ocupados durante una hora entera sin tiempo de inactividad y, por lo tanto, no terminen en absoluto durante esa hora. Esto sólo se registraría como un caso en el que se alcanza el límite de workers PHP y, por tanto, puede parecer que los workers PHP no estuvieron ocupados durante esa hora cuando, en realidad, estuvieron todos activos todo el tiempo. Transcurridos 30 minutos, si se produce una disminución del tráfico que permita que un worker PHP esté inactivo durante 10 segundos, éste terminará automáticamente. Sin embargo, si se vuelve a necesitar el worker PHP en otro minuto, se alcanzaría de nuevo el número máximo de workers PHP, lo que daría lugar a que se registrara otro límite de workers PHP.

Si estás investigando el rendimiento del sitio web y determinando si tu sitio está utilizando continuamente sus workers PHP, puedes monitorizar la actividad de los workers PHP utilizando herramientas en una sesión SSH. Por ejemplo, el siguiente comando personalizado monitoriza el número de workers PHP activos cada 0,3 segundos:

watch -n 0.3 "ps aux | awk '$(NF-2) ~ /php-fpm/ && $(NF-1) ~ /pool/ && $8 ~ /R/ { print $0 }' | wc -l"

Para salir de este comando, pulsa CMD + C o CTRL + C y luego suelta ambas teclas.

Analíticas del caché

Puedes utilizar la sección de analítica de caché de MyKinsta para ver el total de peticiones de caché de tu sitio y las principales omisiones de caché.

Reducir y optimizar el uso de workers PHP

Caché

El almacenamiento en caché es tu mejor amigo cuando se trata de optimizar tu sitio y reducir el número de workers PHP necesarios. Recuerda que los workers PHP no son necesarios para el contenido almacenado en caché, así que almacena en caché todo lo que puedas.

Caché de página

En Kinsta, nos ocupamos del caché de páginas por ti; todos los sitios utilizan el módulo de caché FastCGI de Nginx para un rendimiento superrápido.

Caché de objetos

Añadir un caché de objetos persistente como Redis a tu base de datos puede aumentar el rendimiento y reducir la necesidad de workers PHP. Sin caché de objetos, las consultas a la base de datos MySQL se ejecutan para cada petición, aunque se trate de la misma consulta y los mismos resultados.

Redis almacena los resultados de las consultas a la base de datos en RAM para que PHP pueda obtener esos resultados sin ejecutar la consulta de nuevo. Eliminar la necesidad de consultas repetitivas a la base de datos permite a los workers PHP conservar recursos y satisfacer las peticiones de forma más eficiente.

Consulta nuestros add-ons premium para saber más sobre cómo añadir la caché Redis a tu sitio.

Optimización del código

Asegúrate de que el código de tu sitio está optimizado para que sea lo más eficiente posible. Esto se aplica al código personalizado, al código del tema y al código de los plugins. Si no estás seguro, te recomendamos que pidas a un desarrollador que revise el código de tu sitio.

Código personalizado

Si tu sitio web contiene fragmentos de código personalizado en plugins o en tu tema, asegúrate de que son realmente necesarios y están bien escritos.

Plugins

Echa un buen vistazo a los plugins utilizados en el sitio y asegúrate de que son realmente necesarios, no duplican funciones y son la mejor opción para la necesidad que satisfacen. Si algún plugin no es compatible con la última versión de WordPress y PHP, puede que sea el momento de considerar otras opciones. Si tienes plugins en tu sitio que no se utilizan, se recomienda eliminarlos.

Tema

Utiliza un tema ligero y eficaz. Evita los temas que contengan funcionalidades que se implementan mejor mediante plugins independientes (por ejemplo, SEO, filtros de búsqueda, campos personalizados, sliders/presentaciones de imágenes, etc.) o que no sean necesarios para tu sitio.

Actualiza PHP

Utiliza la última versión de PHP para obtener un rendimiento más rápido. Los benchmarks de PHP muestran que cada versión de PHP es más rápida que la anterior.

Habilitar la CDN de Kinsta

Habilitar la CDN de Kinsta proporciona otro impulso de eficiencia y optimización para tu sitio. La CDN de Kinsta es nuestra CDN HTTP/3 de alto rendimiento impulsada por Cloudflare, que te proporcionamos sin coste adicional. Con ella activada, tu sitio podrá servir activos estáticos desde ubicaciones de todo el mundo.

Consulta con un experto en rendimiento

Si estás familiarizado con la optimización de sitios, este es un paso opcional. Un experto puede ayudarte a analizar todos los aspectos de tus sitios, identificar los cuellos de botella e implementar soluciones.

Reiniciar PHP

Si PHP se cae, nuestro sistema lo registra automáticamente para que nuestro equipo de Administración de Sistemas (sysadmin) lo compruebe. Sin embargo, puedes reiniciar manualmente PHP para cualquiera de tus sitios web individualmente con un simple clic de un botón desde MyKinsta.

Cómo reiniciar PHP de forma manual

Para reiniciar PHP en tu sitio de WordPress, sigue los pasos que se indican a continuación.

1. Inicia sesión en MyKinsta.
2. Ve a Sitios WordPress y selecciona el sitio en el que deseas reiniciar PHP.
3. Ve a la pestaña Herramientas y busca la sección Reiniciar PHP.
4. Haz clic en el botón Reiniciar PHP.

Ten en cuenta que reiniciar PHP tardará unos 5-10 segundos. Recibirás una notificación en la parte inferior de la pantalla cuando se haya completado.

Nota: También tendrás que borrar la caché de tu sitio para ver los cambios.

Límites de PHP

Como servicio Administrado de WordPress, Kinsta tiene configurados los ajustes PHP óptimos para funcionar mejor con los sitios de WordPress. Si tienes requisitos específicos de PHP, no dudes en ponerte en contacto con nuestro Equipo de Soporte para hablar de tus necesidades.

Kinsta ofrece PHP 8.1, 8.2 y 8.3. Estos son los ajustes por defecto para PHP:

• memory_limit = 256M
• post_max_size = 128M
• upload_max_filesize = 128M
• max_input_vars = 10000
• max_execution_time = 300

Si es necesario, puedes aumentar estos valores. Ponte en contacto con nuestro Equipo de Soporte para saber qué opciones tienes a tu disposición.

Límite de memoria PHP

Por defecto, el límite de memoria PHP de Kinsta es de 256 MB, que es más que suficiente para la mayoría de plugins y sitios de WordPress. Este límite existe para evitar que los scripts PHP consuman demasiada memoria. Si estableces un límite demasiado alto, un script mal configurado o roto puede causar graves problemas al consumir demasiada memoria.

Si tu sitio está configurado correctamente en Kinsta, no deberías encontrarte con un error de límite de memoria. Si ves este error, te recomendamos que compruebes la configuración de WordPress para asegurarte de que no se ha establecido accidentalmente a un nivel demasiado bajo.

Si quieres aumentar el límite de memoria PHP de un sitio, puedes comprar un add-on de límite de memoria PHP. Este add-on aumenta el límite de memoria de 256 MB a 512 MB a un coste de 50$ por sitio al mes.

Para comprar este add-on, en MyKinsta, ve a Sitios de WordPress > nombre del sitio > Add-ons, y en Memoria PHP, haz clic en Cambiar.

Se abrirá una nueva ventana con la información de precios; haz clic en Abrir chat para iniciar una conversación con nuestro equipo de Gestión de Cuentas, que configurará el add-on para ti.

También puedes ponerte en contacto con el equipo de Gestión de Cuentas a través del chat en tiempo real del Panel MyKinsta o enviándonos un correo electrónico a [email protected].

Si eliminas el add-on de límite de memoria PHP y estás en los primeros 30 días de tu plan de Alojamiento de WordPress, se añadirá a tu próxima factura un importe prorrateado por el add-on correspondiente al periodo de tiempo en que estuvo activado. Si tu plan de Alojamiento de WordPress lleva activo más de 30 días, recibirás un crédito prorrateado por las tarifas de los add-ons en el saldo de tu cuenta por los días restantes del periodo de facturación actual. El crédito se utiliza automáticamente para compensar el dinero adeudado a Kinsta en tu próxima factura. Para más información, consulta nuestra Garantía de Devolución del Dinero del Alojamiento de WordPress.

Comprobar y cambiar tu límite de memoria PHP

Para comprobar tu límite actual de memoria PHP para WordPress, accede al panel de WordPress de tu sitio y ve a Herramientas > Salud del Sitio.

Ve a la pestaña Información y haz clic en el icono de la flecha situado junto a la sección Servidor para ampliar esta sección y ver tu límite de memoria PHP.

Si el límite de memoria es inferior a 256M, comprueba tu archivo wp-config.php para ver si se ha modificado el WP_MEMORY_LIMIT y ajústalo si es necesario.

Si el límite de memoria es de 256M, pero tienes problemas con la memoria PHP, te recomendamos que revises y compruebes plugins y temas. Puedes utilizar un entorno staging para desactivar y reactivar plugins y temas de forma segura para identificar el origen del uso de memoria.

Si el error persiste y no puedes identificar el origen, puedes abrir un nuevo chat con nuestro equipo de Soporte para comprobar los registros y descartar cualquier problema en el lado del servidor.

Actualizar PHP

Hemos hecho que actualizar la versión PHP de tu sitio a través de MyKinsta sea lo más fácil posible.

En MyKinsta, puedes actualizar la versión de PHP de uno o varios sitios, incluidos los sitios staging, simultáneamente desde la página Sitios de WordPress. Selecciona las casillas de verificación situadas junto a los sitios para los que deseas actualizar la versión PHP, haz clic en Acciones y selecciona Cambiar versión PHP.

Selecciona la versión que deseas actualizar y haz clic en Cambiar versión PHP.

Una vez finalizado el proceso, aparecerá un mensaje de éxito.

También puedes actualizar la versión de PHP de un solo sitio en Sitios de WordPress > nombre del sitio > Herramientas. En Motor PHP, haz clic en el desplegable y selecciona la versión de PHP a la que quieres actualizar tu sitio.

En el modal/pop-up Modificar versión PHP que aparece, haz clic en el botón Modificar versión PHP para confirmar el cambio.

Al final de la actualización, tu motor PHP se reiniciará, y el backend (panel de WordPress) de tu sitio puede estar inactivo durante un par de segundos. El front del sitio permanecerá activo, y los visitantes no experimentarán ningún tiempo de inactividad.

Mientras se ejecuta el proceso de actualización, puedes navegar por otras partes de MyKinsta, pero algunas acciones, como la gestión del caché, no estarán disponibles hasta que se reinicie el motor PHP.

Una vez completada la actualización (normalmente en 3 minutos o menos), recibirás una notificación en MyKinsta de que ha finalizado.

Constantes PHP

Las constantes PHP almacenan valores fijos que permanecen iguales en todo tu sitio. Son automáticamente globales, lo que es ideal para valores a los que es necesario acceder en múltiples lugares.

Si utilizas una configuración de WordPress no estándar, como Bedrock o Trellis, es posible que Kinsta no pueda localizar la variable DB_PASSWORD y, por tanto, no pueda actualizar la contraseña de la base de datos cuando tú:

• Añades un nuevo sitio clonando un entorno existente
• Añades un entorno staging clonando un entorno existente
• Envías el entorno staging a producción
• Restauras una copia de seguridad
• Cambias la contraseña de la base de datos en MyKinsta

Para resolver este problema, Kinsta proporciona la constante PHP SERVER_SECRET_DB_PASSWORD para su uso en los servidores Kinsta. Cuando defines esta constante dentro del archivo config.php, MyKinsta la utiliza para identificar la contraseña de la base de datos de tu sitio. Puedes definirla de la siguiente manera:

define('DB_PASSWORD', defined('SERVER_SECRET_DB_PASSWORD') ? SERVER_SECRET_DB : 'asdijfhkjasdbfkjhbajiksd' );

Puedes definir las siguientes constantes PHP para utilizarlas con los servidores Kinsta:

• SERVER_SECRET_DB_USER
• SERVER_SECRET_DB_PASSWORD
• SERVER_SECRET_DB_HOST
• SERVER_SECRET_DB_NAME

Por ejemplo, puedes definir las constantes en el archivo config.php de la siguiente manera:

define('DB_NAME', defined('SERVER_SECRET_DB_NAME') ? SERVER_SECRET_DB_NAME : 'newsitetest');
define('DB_USER', defined('SERVER_SECRET_DB_USER') ? SERVER_SECRET_DB_USER : 'newsitetest');
define('DB_PASSWORD', defined('SERVER_SECRET_DB_PASSWORD') ? SERVER_SECRET_DB : 'asdijfhkjasdbfkjhbajiksd' );
define('DB_HOST', defined('SERVER_SECRET_DB_HOST') ? SERVER_SECRET_DB_HOST : 'localhost');

Alternativamente, puedes definir las constantes como sigue:

define('DB_NAME',SERVER_SECRET_DB_NAME);
define('DB_USER',SERVER_SECRET_DB_USER);
define('DB_PASSWORD',SERVER_SECRET_DB_PASSWORD);
define('DB_HOST',SERVER_SECRET_DB_HOST);

Módulos PHP

Los siguientes módulos PHP están instalados por defecto en tu sitio de WordPress en Kinsta:

• bcmath
• bz2
• calendar
• Core
• ctype
• curl
• date
• dom
• exif
• FFI
• fileinfo
• filter
• ftp
• gd
• gettext
• hash
• iconv
• igbinary
• imagick
• imap
• intl
• json
• libxml
• mbstring
• mysqli
• mysqlnd
• openssl
• pcntl
• pcre
• PDO
• pdo_mysql
• Phar
• posix
• readline
• redis
• Reflection
• session
• shmop
• SimpleXML
• soap
• sockets
• sodium
• SPL
• standard
• sysvmsg
• sysvsem
• sysvshm
• tokenizer
• xml
• xmlreader
• xmlwriter
• xsl
• Zend OPcache
• zip zlib

ionCube no está instalado por defecto, pero puede activarse si tu sitio ejecuta PHP 8.1, 8.2 o 8.3 en MyKinsta > Sitios WordPress > nombre del sitio > Herramientas > Cargador ionCube > Activar.

Si tienes preguntas sobre un módulo PHP específico no incluido en la lista anterior, ponte en contacto con el Equipo de Soporte de Kinsta.