SSD o NVMe en un hosting: cuándo el disco cambia la velocidad del sitio

Tres tipos de disco, tres órdenes de magnitud

Valores de hoja de datos de equipos actuales. En un servidor real los números bajan, pero la proporción entre uno y otro se mantiene.

Por qué en la mayoría de los sitios no se nota

Linux guarda en memoria lo que lee del disco y lo reutiliza mientras haya lugar. La base de datos hace lo mismo con su propio búfer. En un sitio con tráfico normal, los archivos de PHP, las imágenes más vistas y las tablas que se consultan seguido terminan viviendo en RAM, y el disco casi no trabaja.

Mirá dónde se va el tiempo de una página de WordPress sin caché: PHP ejecutando el tema y los complementos puede llevar de 200 a 800 milisegundos, las consultas a la base suman unas decenas más, y después está la red hasta el visitante. Un acceso a un SSD cuesta una décima de milisegundo. Aunque el NVMe lo baje a la quinta parte, sobre el total de la página la diferencia no llega a verse.

Por eso el salto que sí cambia todo es el de disco mecánico a SSD. Ahí la latencia pasa de milisegundos a fracciones de milisegundo, y un sitio que esperaba al disco en cada consulta deja de hacerlo. Entre SSD y NVMe la mejora existe, pero queda escondida detrás de todo lo demás.

Dónde sí vas a ver la diferencia

• Bases de datos con muchas escrituras: cada pedido confirmado, cada sesión guardada y cada línea de registro obliga al motor a asegurar el dato en disco antes de seguir. Ahí la latencia de escritura pesa directo.
• Sitios sin caché cuya base es más grande que la memoria disponible: cada consulta que no encuentra el dato en RAM va a buscarlo al disco.
• Restaurar una copia, importar una base grande o reconstruir un índice de búsqueda. Son operaciones largas donde el disco sí es el límite.
• Servidores con muchas cuentas o máquinas virtuales leyendo y escribiendo a la vez. Lo que se agota ahí son las operaciones por segundo, no la velocidad de copia.

Cómo saber si el disco te está frenando

En un hosting compartido no tenés acceso a estas métricas, pero en un Cloud VPS o un servidor cloud sí. El paquete sysstat trae iostat, que muestra cada pocos segundos qué tan ocupado está cada disco:

sudo apt install sysstat    # Debian y Ubuntu
sudo dnf install sysstat    # AlmaLinux
iostat -x 5

• r_await y w_await son los milisegundos que espera cada lectura y cada escritura. En un SSD sano están por debajo de 1 o 2 ms; si suben a decenas, hay cola.
• %util cerca de 100 durante minutos indica un disco que no da abasto. En NVMe ese número exagera, porque atiende muchos pedidos en paralelo: ahí mirá sobre todo los tiempos de espera.
• En top, el valor wa es el porcentaje de tiempo que el procesador pasa esperando al disco. Si es alto justo cuando el sitio está lento, encontraste al culpable.
• Si nada de eso se mueve y el sitio sigue lento, el problema está en otro lado: PHP, consultas sin índice, imágenes o una API externa. Una prueba de velocidad bien leída te dice cuál.

Qué probar antes de pagar por un disco más rápido

Qué discos usa InHosting

Los planes de hosting corren sobre discos SSD, con Nginx, HTTP/2 y varias versiones de PHP. Para sitios institucionales, blogs y tiendas chicas y medianas con caché, el disco no es lo que decide la velocidad: pesan más el tamaño de las páginas y lo que hace cada complemento.

En los servidores cloud elegís entre 240 GB SSD o 1 TB SAS, siempre en RAID 10 con un disco de reserva. El RAID 10 reparte las lecturas entre varios discos y guarda cada dato espejado; si un disco falla, el de reserva entra solo. La regla práctica: SSD para la base de datos y el sitio, SAS cuando lo que necesitás es capacidad para archivos, registros o copias.