PHP y rendimiento

Versiones de PHP

OPanel corre PHP 7.4 a 8.5 en simultáneo, coinstaladas en cada servidor web. Cada sitio elige su rama de forma independiente del resto de los sitios en el mismo servidor; cambiar la versión de un sitio simplemente intercambia el binario de su unidad de FPM y el upstream de nginx — no hay un php.ini compartido por el que pelear. Las ramas sin soporte (7.4, 8.0, 8.1; 8.2 después del 31/12/2026) se marcan en la consola, y los operadores pueden restringir qué ramas pueden elegir los clientes.

PHP-FPM y OPcache por sitio

Cada sitio PHP tiene su propio proceso maestro de PHP-FPM, corriendo como el usuario Unix propio de ese sitio dentro de su sandbox, con su propio OPcache. Esta es la diferencia entre OPanel y un pool compartido de php-fpm: la caché de opcode de un sitio nunca puede ser contaminada ni desalojada por otro, y un sitio descontrolado no puede matar de hambre a los workers de PHP de otro — los límites de cgroup se aplican por sitio, no por servidor.

PHP en reposo y scale-to-zero

El proceso maestro de PHP-FPM de un sitio se detiene solo después de un período sin solicitudes — se “duerme” — y la siguiente solicitud lo vuelve a arrancar automáticamente, sin error y sin cortar la conexión: systemd es dueño del socket del sitio, así que las solicitudes esperan en cola el instante que tarda en arrancar el maestro, en vez de fallar. Un sitio dormido no usa nada de memoria de PHP, que es justamente lo que le permite a un servidor chico alojar cómodamente muchos sitios de bajo tráfico.

• Los planes fijan el tiempo de reposo por defecto, en limits.phpSleepMinutes: 0 significa el valor por defecto de la plataforma (15 minutos), -1 mantiene el PHP siempre activo, y puede llegar hasta 1440 (24 horas).
• Los sitios pueden configurar un tiempo más corto que el que permite su plan, o, si el plan incluye la característica “PHP siempre activo”, mantener su propio PHP siempre encendido.
• Las tareas cron, WP-CLI, SSH, SFTP y el administrador de archivos nunca necesitan el maestro, así que ninguno de ellos despierta un sitio dormido — solo lo hace una solicitud real (incluida una tarea cron que consulta el sitio por HTTP).
• Una tienda con actividad constante, o un sitio cuya primera visita nunca debe esperar, conviene dejarlos siempre activos.

La consola muestra el estado actual de cada sitio (despierto/dormido), cuánto tiempo lleva despierto y su historial de activaciones; las métricas a nivel de nodo muestran la memoria total ahorrada por los sitios dormidos.

Caché con Valkey

Cada sitio tiene su propia instancia de Valkey, o un usuario ACL restringido a su propio prefijo de claves en un pool compartido. Los planes fijan un límite de tamaño de caché (limits.cacheMB); 0 significa sin caché.

HTTP/3 y el edge

El proxy edge está escrito en Go y termina HTTP/1.1, HTTP/2 y HTTP/3 (QUIC) con certificados TLS automáticos y bajo demanda. Habilitar HTTP/3 necesita buffers UDP del kernel generosos; opanel doctor lo verifica y avisa si los límites del kernel son demasiado bajos. Las recargas y actualizaciones del edge le pasan los sockets de escucha a un proceso nuevo sin cortar ninguna conexión — las solicitudes HTTP normales drenan hasta 5 minutos, HTTP/3 (que no puede migrar en medio de una conexión) hasta 5 segundos, tras lo cual los navegadores se reconectan por HTTP/2.

Configuración de PHP y topes

Los clientes ajustan la configuración de PHP de su propio sitio — memory_limit, upload_max_filesize, max_execution_time y más — desde una lista permitida, limitada por los topes que fija el plan:

Límite del plan	Gobierna
phpWorkers	Máximo de procesos worker de FPM para el sitio
phpMemoryLimitMB	Tope para el memory_limit del sitio
maxUploadMB	Tope para upload_max_filesize / post_max_size
maxExecutionSeconds	Tope para max_execution_time
phpSleepMinutes	Tiempo de reposo por defecto y mínimo que puede fijar el sitio

Los operadores también pueden deshabilitar funciones específicas de PHP en todo el clúster (disableFunctions en la configuración de la plataforma) — útil para funciones que nunca quieres que ningún inquilino invoque, sea cual sea su plan.

Límites de recursos, de un vistazo

Cada plan lleva un conjunto completo de límites por suscripción y por sitio, aplicados con cgroups: cpuPercent, memoryMB, tasks (tope de procesos/hilos) e ioWeight. Ver Planes para la lista completa y los valores por defecto recomendados.