VPS nuevo y la tienda sigue lenta: vCPU dormidas y socket a MySQL

En noviembre de 2026 Gustavo, de la comunidad, compartió el resultado de optimizar una tienda recién pasada a un VPS. El servidor nuevo era mejor, pero la tienda no iba todo lo rápido que debía. Respuesta corta: en una máquina virtual, las vCPU se duermen entre consulta y consulta y tardan en despertar; con unas 680 consultas en la portada, esos despertares suman. Un ajuste de Linux para máquinas virtuales y conectar con la base de datos por socket casi duplicaron la velocidad.

Qué pasa con las vCPU

Los procesadores de un VPS (vCPU) son trozos del procesador real del proveedor. Cuando una vCPU no tiene trabajo, se duerme; cuando le llega trabajo, tarda un poco en despertar.

En una página de la tienda eso ocurre cientos de veces: PHP pide un dato a la base de datos, la base de datos estaba dormida y tarda en despertar, contesta, y ahora es PHP el que se había dormido esperando. Cada espera es mínima, pero la portada de esta tienda hacía unas 680 consultas.

El ajuste: haltpoll

Linux trae para máquinas virtuales un controlador llamado cpuidle-haltpoll. Hace que la vCPU espere unos microsegundos antes de dormirse; como la respuesta suele llegar en ese rato, ya no hay que despertarla.

• Resultado medido: cada consulta pasó de 0,22 ms a 0,06 ms.
• A cambio, el procesador trabaja un poco más mientras espera, sin efecto apreciable.
• Se deshace borrando el fichero de configuración que lo activa.

Para ver qué controlador usa tu servidor:

cat /sys/devices/system/cpu/cpuidle/current_driver
cat /sys/devices/system/cpu/cpuidle/current_governor_ro

Esto solo tiene sentido en un VPS o servidor virtual en el que tengas acceso de administrador. En un hosting compartido no se puede tocar.

El otro ajuste: socket en lugar de red

Además, la tienda pasó a hablar con la base de datos por un canal interno del propio servidor (socket) en lugar de por la red local, que es algo más rápido. Solo vale cuando la base de datos está en la misma máquina que la web.

En PrestaShop el servidor de base de datos está en app/config/parameters.php, en database_host. Con los controladores MySQL de PHP, localhost suele conectar por socket y 127.0.0.1 por TCP. Si lo cambias, comprueba que PHP encuentra el socket de tu base de datos y prueba la tienda entera.

Los números

Sin cambiar de CPU. Gustavo comprobó después, entrando como un cliente, que portada, ficha, blog, carrito, checkout y back-office funcionaban, y que los cambios seguían activos tras reiniciar.

Otras cosas que mirar en un VPS

• El «CPU steal». En septiembre Gustavo preguntó si se podía pedir al proveedor que no ocurriera. Otro miembro del grupo matizaba: un porcentaje alto no siempre es que te «roben» CPU; puede ser que la máquina esté al 100 % y esperando. Aun así, si es alto de forma sostenida, pregunta al proveedor si la máquina física está sobrevendida.
• La caché de rutas de PHP. Gustavo tiene publicada una guía sobre realpath_cache con resultados medidos: con decenas de miles de ficheros PHP, como en PrestaShop, es otro ajuste barato.
• Mide antes de tocar. Tiempos de la portada, una ficha y una búsqueda, y el número de consultas por página. Sin esa foto inicial no sabrás qué ha servido.

Para el lado de PrestaShop, el módulo de caché con Redis y OPcache y RKR Diagnoses, que te dice cuántas consultas hace cada página y cuáles pesan.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación