Tutoriales de VPS
Cómo hacer pruebas de rendimiento en un VPS (2026): cómo leer los resultados de YABS, fio, iperf3 y Geekbench
Muchas personas compran un VPS y lo primero que hacen es ejecutar un script, hacer una captura y enviarla al grupo: cuánto puntúa la CPU, cuántos MB/s da el disco, a cuántos Gbps llega la red, y luego concluyen si la máquina vale la pena. El problema es que ejecutar las pruebas no es difícil; lo realmente difícil es entender qué representan. YABS, fio, iperf3 y Geekbench miden dimensiones distintas, y mirar cualquiera de ellos por separado lleva fácilmente a conclusiones erróneas.
Muchas personas, después de comprar un VPS, lo primero que hacen no es desplegar nada, sino ejecutar una ronda de pruebas.
Es normal.
Al fin y al cabo, acabas de adquirir una máquina y lo que más quieres confirmar es probablemente esto:
- Si la CPU está sobrevendida o mal etiquetada
- Si el disco "parece rápido pero en cuanto escribes de verdad se desploma"
- Si la red se ve bien de día y se cae por la noche
- Si esta máquina es realmente adecuada para tu carga de trabajo
Y ahí está justamente el problema.
Muchas personas ejecutan un script y sacan conclusiones directamente:
- Esta máquina es potente
- Esta máquina no vale la pena
- Este proveedor es estable
- Este VPS es una bestia
Pero la verdad normalmente no es tan simple.
Porque YABS, fio, iperf3 y Geekbench miden cosas distintas, y si los mezclas o miras solo un número, es fácil equivocarse.
Así que este artículo no solo enseña "cómo ejecutarlos", sino que se centra en:
- Qué mide realmente cada herramienta
- Qué resultados se malinterpretan con más facilidad
- Qué resultados son más útiles para sitios web, desarrollo, descargas, bases de datos y proxies
- Después de una ronda completa, cómo deberías juzgar de verdad
1) Primero la conclusión: las pruebas no son para hacer capturas, sino para juzgar "si esta máquina es adecuada para mi escenario"
El mayor problema de muchos artículos sobre pruebas de VPS es que convierten las pruebas en un juego de clasificaciones.
Pero para la mayoría de usuarios, en realidad solo hay una pregunta útil:
- ¿Puede esta máquina soportar mi carga de trabajo real?
Así que antes de ejecutar pruebas, no te apresures a lanzar comandos: primero aclara qué quieres verificar.
Deberías preocuparte más por:
- Rendimiento de un solo núcleo
- Lectura/escritura aleatoria del disco
- Estabilidad de la red
Deberías preocuparte más por:
- Ancho de banda de salida
- Rendimiento de red sostenido en el tiempo
- Escritura secuencial del disco
Deberías preocuparte más por:
- Estabilidad de la CPU
- I/O aleatorio
- Comportamiento bajo presión de memoria
Así que las pruebas no consisten en "qué herramienta es más avanzada", sino en:
- Usar la herramienta adecuada para medir la capacidad que realmente vas a utilizar.
YABS es popular por una razón sencilla:
- Se ejecuta con un solo comando
- CPU, disco, red y Geekbench salen de paso
- Es muy útil para tener una visión general la primera vez que recibes una máquina
Ejecución típica:
curl -sL yabs.sh | bash
Te da algunos resultados bastante habituales:
- Información básica de la CPU
- Pruebas de disco con fio
- Pruebas de velocidad de red
- Geekbench en algunos entornos
- Cómodo
- Rápido
- Adecuado para una primera revisión
Muchas personas tratan YABS como la "conclusión final".
Eso es un error.
Porque YABS se parece más a:
- Un punto de entrada general
Y no a:
- Una herramienta de diagnóstico profundo
Si solo quieres saber a grandes rasgos en qué nivel está esta máquina, YABS es adecuado.
Pero si de verdad quieres juzgar la calidad del disco, el rendimiento de red o la capacidad de la CPU bajo carga prolongada, YABS es solo el principio, no el final.
Las pruebas de disco son las más fáciles de malinterpretar.
Muchas personas se emocionan al ver resultados como:
- 3000 MB/s
- 5000 MB/s
- 7000 MB/s
Y entonces piensan:
- Este disco es una pasada
El problema es que estas cifras normalmente solo muestran una cosa:
- La lectura/escritura secuencial se ve muy bien
Pero en cargas reales, muchos cuellos de botella no vienen de ahí.
- Lectura/escritura aleatoria
- I/O de bloques pequeños
- Estabilidad bajo alta concurrencia
Por eso los resultados de fio no se pueden juzgar mirando solo un valor máximo.
Lo más significativo es mirar:
- Lectura/escritura aleatoria de 4K
- IOPS
- Latencia
- Si se desploma mucho con distintos tamaños de bloque
Algunos VPS tienen una escritura secuencial excelente, pero:
- La escritura aleatoria es mediocre
- La latencia fluctúa mucho
- La velocidad cae tras escribir un rato
Para ejecutar logs, bases de datos o escrituras de caché frecuentes, una máquina así se siente completamente distinta.
Así que al mirar fio, no mires solo:
- El MB/s máximo
Mira más bien:
- Si este disco es estable con archivos pequeños reales y escrituras de bloques pequeños.
Si solo echas un vistazo a la gráfica de la prueba, es fácil confundir un disco "bueno para transferencia secuencial de archivos grandes" con uno "bueno para todas las cargas".
iperf3 tiene mucho valor, pero también es una de las herramientas que más se usan mal.
La pregunta que mejor responde es:
- Cuánta capacidad de rendimiento de red hay entre dos puntos
Por ejemplo:
iperf3 -c <server-ip>
O la prueba inversa:
iperf3 -c <server-ip> -R
- Medir el ancho de banda de la red interna
- Medir el rendimiento desde una sonda fija hasta el VPS
- Comparar cambios de capacidad de red en distintos periodos
- "Todos mis usuarios globales tendrán esta velocidad"
- "La red pública del proveedor seguro que es así de potente"
- "Dio 5Gbps en la prueba, así que la descarga real seguro que es 5Gbps"
Porque iperf3 mide:
- Un endpoint de prueba concreto
- Condiciones de ruta concretas
- Una ventana de tiempo concreta
Esto significa que el mismo VPS:
- Puede dar muy buenos resultados hacia Tokio
- Resultados normales hacia Los Ángeles
- Y ser completamente distinto hacia China continental en hora punta nocturna
Así que el valor central de iperf3 no es demostrar "lo increíble que soy", sino:
- Ayudarte a ver si hay un cuello de botella en una dirección de red concreta.
Si quieres juzgar la calidad de la ruta de red pública, iperf3 se combina mejor con:
pingtraceroutemtr
y se miran juntos.
Para ideas relacionadas sobre pruebas de red, puedes seguir leyendo:
El mayor valor de Geekbench es darte una puntuación de referencia de CPU bastante estandarizada.
Para lo que sirve:
- Comparar a grandes rasgos la capacidad de un solo núcleo y de varios núcleos entre máquinas
- Juzgar aproximadamente en qué nivel está la CPU de este VPS
- Ayudar a identificar máquinas con "especificaciones muy buenas pero un solo núcleo débil"
Esto tiene sentido en muchos escenarios, como:
- WordPress
- APIs pequeñas
- Paneles y servicios de backend
- Entornos de desarrollo ligeros
Porque estos escenarios suelen ser sensibles al rendimiento de un solo núcleo.
No puede decirte directamente:
- Si habrá throttling bajo carga alta prolongada
- Si habrá fluctuaciones cuando los vecinos acaparen recursos
- Si el disco y la red van a arrastrarlo
- Si tu aplicación real funcionará con fluidez
Así que Geekbench se parece más a:
- Una referencia de capacidad de CPU
Y no a:
- Una conclusión de carga real para toda la máquina
Si una máquina tiene un Geekbench decente pero el disco es malo, la red es mala y hay mucha contención en el host, la experiencia real puede seguir siendo mediocre.
Si no quieres complicar demasiado el proceso, te sugiero este orden.
Objetivo:
- Ver rápidamente el nivel aproximado de CPU, disco y red
- Juzgar si hay alguna anomalía evidente
Objetivo:
- Juzgar el I/O aleatorio y la latencia del disco
- Ver si existe el caso de "buena escritura secuencial, mucho peor aleatoria"
Objetivo:
- Medir el rendimiento de red en la dirección que realmente te importa
- Comparar diferencias entre nodos y periodos
Es decir, no mires solo si la puntuación de Geekbench es alta, sino piensa una cosa:
- Tu carga depende más de un solo núcleo, del I/O o de la red
La ventaja de este orden es:
- No te dejarás llevar por un solo script
- No forzarás los números de cada herramienta en un único "valor de potencia global"
Aquí tienes un marco de juicio más práctico.
Esto normalmente indica que el problema no está en la potencia de cálculo pura, sino posiblemente en:
- Latencia del disco
- Contención en el host
- Inestabilidad de la red
Una máquina así para:
- Descargas de archivos grandes
- Almacenamiento de datos fríos
puede ir bien.
Pero para:
- Bases de datos
- Sitios dinámicos
- Escrituras de caché de alta frecuencia
es posible que no sea cómoda.
Esto significa:
- Lo que mediste es el rendimiento de una sola ruta
- No la experiencia completa del usuario
En este caso deberías volver a revisar:
- MTR
- Rutas de ida/vuelta
- Comportamiento en hora punta nocturna
Este tipo de fluctuación a veces preocupa más que "no ser alto de media".
Porque a menudo significa:
- Recursos inestables
- Gran impacto de los vecinos
- Carga desigual en el host
Y lo que más temen las cargas reales a menudo no es "medio", sino "inestable".
Prioriza:
- Puntuación de un solo núcleo
- I/O aleatorio de 4K
- Estabilidad de la red
Prioriza:
- Estabilidad de un solo núcleo + varios núcleos
- Lectura/escritura aleatoria del disco
- Fluctuación de latencia
Prioriza:
- Rendimiento de salida
- Estabilidad del ancho de banda en el tiempo
- Lectura/escritura secuencial de archivos grandes
Prioriza:
- Rendimiento general de la CPU
- Fundamentos del disco
- Si la máquina es estable
Solo cuando haces coincidir el "tipo de carga" con la "salida de la herramienta" los resultados de las pruebas tienen verdadero sentido.
Muchos VPS parecen tener buenas puntuaciones, pero por la noche están en un estado completamente distinto.
Esto es especialmente común en:
- VPS compartidos baratos
- Hosts con mucha contención
- Rutas de gran ancho de banda pero congestionadas en hora punta
Así que un enfoque más fiable es:
- Ejecutar una vez de día
- Ejecutar otra vez en hora punta nocturna
- Comparar la diferencia al menos una vez
Especialmente cuando estás mirando:
- Rendimiento de red
- Jitter de latencia
- Fluctuación del host
Si los resultados fluctúan mucho, aunque el pico sea alto, no necesariamente vale más la pena conservarla que una máquina "menos espectacular pero más estable".
Si más adelante quieres ver datos comparativos trimestrales, también puedes consultar:
10) Última palabra: el objetivo de las pruebas no es "sacar una puntuación alta", sino "entender cómo afectará esta máquina a tu carga de trabajo"
YABS, fio, iperf3 y Geekbench tienen valor.
Pero su verdadero significado no es que publiques capturas en redes sociales o en grupos, sino ayudarte a responder esta pregunta:
- ¿Es este VPS realmente adecuado para mi escenario real?
Así que el orden más fiable siempre es:
- Primero aclara qué estás midiendo
- Luego mira qué señales te da cada herramienta
- Por último, mapea los resultados a las necesidades de tu carga de trabajo
Con solo hacer esto, las pruebas dejarán de ser "ejecutar un montón de números y quedar más confundido" y se convertirán en un paso que realmente te ayuda a decidir.