Cómo elegir su servidor
Sometimos una instancia en producción a una prueba real con un embudo activo y medimos todo. El resultado: incluso en el VPS más modesto a ~$20/mes (4 vCPU / 8 GB), Qubix sirve ~1.900 vistas de landing por segundo — decenas de millones de visitas al mes — cada una en ~25 ms y con cero errores bajo carga. Todo el servicio cabe en ~1,3 GB de RAM, no tiene fugas de memoria y está diseñado para funcionar 24/7.
Y eso no es el techo: en 12 núcleos ya se alcanzan ~6.800 vistas por segundo — el rendimiento crece de forma lineal con el número de núcleos.
A continuación: qué servidor elegir según su tráfico y los resultados completos de las pruebas que respaldan estos números.
Qué servidor elegir
| Su tráfico (aprox.) | Servidor | Rendimiento |
|---|---|---|
| hasta ~5M visitas/día (picos de hasta ~1.000/s) | 4 vCPU / 8 GB (~$20/mes) | ~1.900 vistas/s — medido, landing en ~25 ms |
| ~5–15M/día (picos ~1.000–3.000/s) | 8 vCPU / 16 GB | ~4.000 vistas/s — estimado (~500 por núcleo) |
| 15M+/día (picos 5.000+/s) | 12 vCPU / 16 GB | ~6.800 vistas/s — medido |
Regla simple: núcleos ≈ pico de visitas por segundo ÷ 500. 8 GB de RAM son suficientes para la configuración recomendada; 16 GB dan margen adicional.
Cuánto soporta — y cómo lo medimos
Condiciones de la prueba:
- Servidor bajo prueba: un VPS en la nube de DigitalOcean — 4 vCPU / 8 GB, SSD, Debian 13 (kernel 6.12), región Frankfurt. Una máquina ordinaria, sin optimizaciones especiales, por ~$20/mes.
- Generador de carga: un servidor separado (12 núcleos) — para que la instancia destine sus recursos solo a su propio trabajo y no a la prueba en sí. Herramienta — bombardier (HTTP con keep-alive), escalando de 50 a 1000 conexiones concurrentes, 15–30 segundos por ejecución.
- Qué cargamos: un embudo real configurado — un dominio real sirviendo un landing cloakeado (~45 KB) con una decisión de cloaking activa, más postbacks de conversión.
- Qué observamos: CPU, memoria, swap y latencia — en tiempo real durante toda la prueba.
- Para escalar ejecutamos la misma prueba en un servidor de 12 vCPU / 64 GB.
Servidor recomendado, 4 vCPU / 8 GB:
| Tipo de solicitud | Capacidad | Latencia | Errores |
|---|---|---|---|
| Landing completo (cloakeado, ~45 KB) | ~1.900/s | ~25 ms (incluso con 250 concurrentes — 0,13 s) | 0 |
| Postback de conversión | ~13.000/s | ~25 ms | 0 |
| Solicitud ligera | ~16.000/s | ~20 ms | 0 |
Ni un solo error con hasta 1000 conexiones concurrentes. Bajo sobrecarga, la instancia no se cae ni descarta solicitudes — solo aumenta la latencia (de ~25 ms a 0,13–0,26 s cuando la carga supera ampliamente la capacidad nominal), y en cuanto el pico cede, el tiempo de respuesta vuelve a la normalidad.
Qué lo limita en el pico. Los 4 núcleos funcionan al 95–100% — el límite es la CPU, por eso la capacidad escala con los núcleos. La memoria se mantuvo estable: entre 1,1 y 1,3 GB bajo carga, sin swap, con más de 3,8 GB siempre libres.
La memoria no tiene fugas. Ejecutamos por separado cuatro ciclos de carga seguidos con pausas y observamos la memoria: en reposo el servicio usaba unos 0,7 GB, bajo carga máxima subía a aproximadamente 1,2 GB, y en las pausas regresaba a ~0,8 GB — sin acumulación de ciclo en ciclo. La instancia es apta para operación continua 24/7.
Escalado por núcleos. La misma prueba en un servidor de 12 vCPU:
| Servidor | Landing completo | Solicitud ligera |
|---|---|---|
| 4 vCPU | ~1.900/s | ~16.000/s |
| 12 vCPU | ~6.800/s | ~80.000/s |
El rendimiento crece en proporción al número de núcleos — aproximadamente 500 vistas de landing por segundo por vCPU (medido: de 475 a 567). De ahí la regla de dimensionamiento de núcleos indicada arriba.
Con Cloudflare — aún más rápido, y gratis
Qubix sirve cualquier dominio a través de Cloudflare — una red global de servidores — y se encarga del DNS y el SSL por usted. La carga más rápida está activada por defecto (adminístrela en Settings → Cloudflare): los archivos estáticos de su sitio (scripts, estilos, iconos y capturas de pantalla) se sirven al visitante desde el servidor de Cloudflare más cercano.
- Mucho más rápido para el visitante — los archivos de la página llegan desde el servidor de Cloudflare más cercano, no desde su servidor al otro lado del mundo. Los landings se abren casi al instante en cualquier parte del mundo.
- Decenas de veces menos carga en su servidor — cada página descarga docenas de archivos estáticos (scripts, estilos, iconos, capturas de pantalla), y Cloudflare los sirve desde sus servidores. Su servidor solo gestiona la parte dinámica — con el mismo hardware puede atender decenas de veces más visitantes.
- Gratis — tanto la red de Cloudflare como el caché no cuestan nada, y Qubix lo configura todo por usted.
La parte dinámica — la decisión de cloaking y el propio landing — sigue ejecutándose en su servidor (eso es exactamente lo que miden los números anteriores); Cloudflare se ocupa de todo lo que lo rodea. Más información en Dominios.
Cuánto espacio en disco necesita
A pleno rendimiento — grabación de pantalla de cada visita, todas sus estadísticas y el embudo, más su biblioteca de creativos — 20 GB cubre alrededor de 300.000 visitas al mes y aguanta durante años: las grabaciones de más de un año se eliminan automáticamente, y el historial de tráfico añade solo ~0,5 GB al año. El verdadero consumidor de disco es su biblioteca de creativos (se conserva de forma permanente): cuanto mayor sea la biblioteca, más espacio necesitará. Incluso aquí Qubix ahorra espacio — nunca almacena el mismo creativo dos veces (la deduplicación detecta incluso copias ligeramente modificadas), y esa misma función potencia sus estadísticas (un creativo presente en cientos de anuncios cuenta como uno solo, con un ROAS combinado). 20 GB equivalen a aproximadamente 2.500 vídeos o 30.000 imágenes; si carga muchos más (un millón de creativos ya son terabytes), tome un disco proporcionalmente mayor — que puede ampliar en cualquier momento.
SSD o HDD — puede ahorrar aquí. Las páginas se abren igual de rápido para los visitantes en cualquier tipo de disco, por lo que puede tomar sin problema un servidor HDD más económico. La diferencia con SSD solo se nota dentro del panel de administración y únicamente a grandes volúmenes: los informes leen el historial del disco y se generan algo más lento en HDD — esto no afecta en absoluto la velocidad de apertura de los landings para los visitantes.