Un pico de tráfico 10× puede multiplicar la latencia p99 y dejar inaccesible una tienda WordPress aun con mucha RAM. Los responsables técnicos suelen fijarse en CPU y memoria y no miden RPS ni p95/p99 sostenidos; eso oculta cuellos de botella reales y genera costes inesperados en momentos críticos.
Se necesita un hosting para alta concurrencia que mantenga WordPress estable bajo picos: infraestructura escalable (load balancer, autoscaling), caching a nivel aplicación y CDN, base de datos optimizada y colas.
El artículo incluye un script básico de k6 y una metodología resumida para pruebas; para facilitar la reproducción completa de los tests se incorporan ejemplos ampliados en el cuerpo (script k6 con fases y thresholds, instrucciones para exportar métricas a InfluxDB/Grafana) y se ofrece un repositorio con configuraciones para nginx, docker-compose y playbooks que permiten repetir las pruebas y comparar RPS, p95 y p99 entre proveedores.
Hosting para alta concurrencia: factores decisivos
La elección de hosting debe basarse en RPS y p95/p99, no solo en RAM o CPU.
Medir p95 y p99 bajo carga sostenida revela los cuellos de botella reales.
Cualquier decisión sin pruebas sostenidas suele llevar a subestimaciones costosas.
Capacidad real: RPS y latencias
RPS indica cuántas peticiones por segundo sirve la infraestructura.
La latencia p95 muestra cuánto tarda el 95% de las peticiones.
El p99 refleja los colapsos raros que definen la experiencia del usuario.
Separación de capas y su impacto
Separar web, PHP, caché y DB reduce bloqueos entre componentes.
Una arquitectura en capas permite escalar cada pieza por demanda.
Warming de caché antes de picos evita fallos iniciales por caché fría.
Coste y dimensionado como variables
El coste real depende de RPS sostenido y complejidad de la app. Como orientación muy general, una vCPU en entornos PHP/WordPress optimizados puede sostener entre ~50 y ~200 RPS, pero la cifra real depende críticamente del cache hit ratio, tipo de contenido dinámico, latencia a la base de datos y tamaño medio de respuesta; siempre conviene medir RPS_por_vCPU en pruebas controladas y usar ese valor para dimensionar con buffer.
Calcular memoria por proceso y añadir un buffer del 30 a 50%.
Un ejemplo: para 500 RPS cacheadas, planear 6 vCPU y 12 GB RAM, más CDN y DB gestionada, da margen para picos sostenidos.
Arquitectura práctica para picos sostenidos
La solución más segura separa balanceador, nodos web PHP, caché y DB replicada.
Cada capa aporta control y permite escalar por cuello de botella.
El diseño debe incluir CDN y WAF para reducir carga directa al origen.
Diseño recomendado
Usuario → CDN/WAF → Load Balancer → NGINX reverse proxy → PHP-FPM nodes.
Object cache (Redis) reduce consultas y read replicas alivian la DB primaria.
Queues fuera de línea gestionan tareas pesadas, como envío de emails.
Kubernetes o VMs: pros y contras
Kubernetes ofrece autoscaling fino y despliegue reproducible.
VMs o VPS simplifican operaciones y bajan la curva de aprendizaje.
La elección depende del equipo: si falta DevOps, usar DB gestionada.
CDN y WAF en la primera línea
CDN reduce RPS hacia el origen y mejora TTFB para usuarios en España.
WAF y mitigación DDoS protegen durante picos maliciosos o tráfico inesperado.
Cloudflare y Akamai ofrecen reglas y caché configurables para WordPress.
flujo simplificado de una arquitectura para picos sostenidos
Junto a la arquitectura recomendada es muy útil disponer de configuraciones listas para replicar ambientes de alta concurrencia: ejemplo de bloque nginx con fastcgi_cache y reglas de purga, docker-compose que despliega NGINX reverse proxy + PHP-FPM pools + Redis como caché de objetos y cola, y un playbook Ansible para ajustar pm.max_children según memoria por proceso. En NGINX conviene usar fastcgi_cache_path con keys por host y cache_lock para evitar stampedes; en PHP-FPM calcular pm.max_children = floor(RAM_disponible_MB / memoria_por_proceso_MB) y activar OPcache.memory_consumption = 128 para reducir compilaciones.
Tener estos archivos (nginx.conf, docker-compose.yml, ansible playbook, scripts de warm-up y k6 avanzados) permite reproducir tests en entornos locales y en la nube, acelerando validación de escalado y ajustes de caché de página y caché de objetos (Redis).
Caching, CDN y configuración para picos
El primer alivio ante picos es cachear al máximo y evitar pasos a la DB.
Caché de página y caché de objetos reducen RPS internos de forma drástica.
La caché debe calentarse antes del pico para evitar ráfagas de consultas.
Cache de página y object cache
Usar fastcgi_cache en NGINX o Varnish para páginas públicas.
Usar Redis para caché de objetos y session store compartido.
Medir cache hit ratio: un 90% de aciertos reduce significativamente la carga en la DB.
PHP-FPM y OPcache: ajustes concretos
Calcular pm.max_children por memoria por proceso y RAM disponible.
2 GB RAM dedicados, 40 MB por proceso → ~50 procesos posibles.
Habilitar OPcache con 128–256 MB para reducir compilación de PHP.
CDN, HTTP/2 y HTTP/3
Activar HTTP/2 mejora multiplexing; HTTP/3 reduce latencia en redes móviles.
Usar Brotli o Gzip para reducir tamaño de respuesta y mejorar TTFB.
Verificar que el CDN soporta HTTP/3 si la latencia geográfica es crítica.
Escalado, balanceo y bases de datos
El escalado horizontal permite repartir la carga y mantener latencias bajas.
El balanceador debe soportar health checks y reequilibrado rápido.
La base de datos necesita réplicas de lectura y optimización de consultas.
Autoescalado y warming de cache
Autoescalado suma nodos cuando sube la carga y los quita luego.
El calentamiento de caché puede automatizarse, pero no es una funcionalidad intrínseca del autoescalado: requiere jobs o scripts que pre-calienten fastcgi_cache/Redis o un proceso de warm-up (k6, curl) que se ejecute al iniciar nodos nuevos antes de enrutarles tráfico de producción.
Sin warming la primera ola puede saturar la DB y crear errores.
MySQL/MariaDB: tuning para concurrencia
Limitar conexiones entrantes y usar connection pooling cuando sea posible.
Configurar índices y monitorizar queries lentas con slow query log.
Considerar motores de almacenamiento optimizados para lecturas intensas.
Colas, tareas y offload
Encolar procesos pesados reduce latencia de respuesta para el usuario.
Usar Redis Streams o RabbitMQ para trabajos asincrónicos y reintentos.
Externalizar backups y procesos de informe evita picos en la DB principal.
Errores y advertencias al elegir hosting
El error más frecuente es confiar solo en las especificaciones del plan.
La mayoría de guías aconseja mejorar la capa web; lo que no mencionan es la DB.
Ignorar límites de conexiones y PHP-FPM suele producir caídas en picos.
Fallos típicos en proveedores
Hosting compartido suele imponer límites de procesos y conexiones.
En picos esos límites generan colas y timeouts en PHP-FPM.
Para e-commerce con picos, evitar compartido y elegir cloud con escalado.
Configuración por defecto que falla
Valores por defecto de PHP-FPM y MySQL suelen ser conservadores.
No ajustar ulimit y net.core.somaxconn puede limitar la concurrencia.
Realizar pruebas de carga revela si los límites del SO son el problema.
Casos reales en España
Un caso habitual: tienda WooCommerce durante oferta cae por DB saturada.
Resultado: checkout fallidos y pérdida de ventas por minutos críticos.
La solución fue separar DB, añadir read replicas y caché de página.
La evidencia indica que WordPress domina gran parte de la web:
| Proveedor |
Autoscaling |
CDN/WAF |
DB gestionada |
Rango precio estim. |
| Kinsta / WP Engine |
Limitado / Gestionado |
Sí (integrado) |
Sí |
Desde 200€+/mes por sitio |
| AWS / GCP / Azure |
Completo (autoscaling) |
Via Cloudflare/Akamai |
RDS / Cloud SQL |
Desde 150€+/mes según uso |
| DigitalOcean / OVHcloud |
Sí, con configuración |
Opcional |
Managed DB opcional |
Desde 40€+/mes para setups básicos |
| Hosts españoles (SiteGround, Webempresa) |
Limitado, revisar SLA |
Integrado en algunos planes |
No siempre |
Desde 20€+/mes, según plan |
Los precios son orientativos y varían según tráfico real y copias de seguridad retención.
Opinión con matiz: Para picos sostenidos, preferir cloud público con autoscaling y DB gestionada funciona bien, pero solo si existe procesos para calentar la caché y gestionar despliegues. Si falta ese equipo, una solución managed con SLAs altos suele ser más segura y previsible. La recomendación final depende del coste aceptable y la capacidad interna para operar la infraestructura.
Para avanzar con seguridad, solicitar un análisis técnico con pruebas reproducibles y estimación de costes suele ser la opción más práctica.
No aplicar estas recomendaciones si el sitio tiene tráfico bajo y estable o si se usa una plataforma SaaS con escalado incluido; en esos casos basta con hosting gestionado básico y CDN.
- Para estimar coste por RPS o usuarios simultáneos conviene convertir concurrencia a RPS usando la relación RPS ≈ usuarios_concurrentes / tiempo_medio_entre_peticiones(seg). Por ejemplo, 1.000 usuarios concurrentes con think time medio 10 s generan ~100 RPS
- Si medimos RPS_por_vCPU_real = 150 en pruebas, necesitaremos ≈ ceil(100/150)=1 vCPU, añadir buffer del 50% → 2 vCPU. Al coste de compute hay que sumar DB gestionada (replica de lectura) y CDN: si la transferencia estimada es 500 GB/mes, con precios CDN entre 0,01–0,08 €/GB el coste variará de 5–40 €/mes
- Una instancia cloud de 2 vCPU + 4–8 GB RAM puede costar en cloud público entre 20–60 €/mes según proveedor, y una DB gestionada con réplicas puede añadir 50–200 €/mes
Este desglose por RPS permite comparar soluciones managed vs cloud y decidir según presupuesto y necesidad de escalado automático.
## Preguntas frecuentes
### ¿Qué hosting es mejor para picos de tráfico?
Depende del control y presupuesto disponibles.
Managed WordPress facilita operaciones y soporte. Cloud público ofrece control y autoscaling.
Elegir según si existe equipo DevOps para operar la infraestructura.
### ¿Cómo medir si mi hosting aguanta un pico?
Hacer pruebas sostenidas con k6, 5–15 minutos por escenario.
Medir RPS, p95 y p99, tasa de errores y TTFB durante la prueba.
Ejecutar warm-up de caché antes de tomar métricas finales.
### ¿Cuánto tráfico puede manejar una vCPU?
Una vCPU bien configurada maneja entre 50 y 200 RPS.
La variación depende de cache hit ratio y complejidad de la página.
Dimensionar con ejemplos reales y añadir buffer del 30–50%.
### ¿Basta un CDN para soportar picos?
Un CDN reduce carga pero no siempre basta.
Si la app tiene muchas peticiones dinámicas, el origen sigue recibiendo tráfico.
Combinar CDN con caché de objetos y DB optimizada para mejores resultados.
### ¿Qué ajustes PHP-FPM son críticos en picos?
Calcular pm.max_children según memoria por proceso y RAM disponible.
Habilitar OPcache y ajustar timeouts para evitar procesos colgados.
Vigilar uso de memoria por proceso en producción y ajustar valores.
### ¿Cómo reducir p99 en situaciones reales?
Detectar queries lentas y eliminarlas o cachearlas.
Aumentar réplicas de lectura y usar connection pooling con límites controlados.
Identificar y encolar procesos pesados fuera del flujo síncrono.
## Qué hacer ahora
Paso 1: definir RPS objetivo y p95/p99 aceptable.
Paso 2: reproducir un escenario con k6 y warm-up de caché.
Paso 3: calcular vCPU y memoria con la fórmula y comparar proveedores.
Ejemplo de script básico k6:
import http from 'k6/http';
import { sleep } from 'k6';
export let options = {
stages: [
{ duration: '2m', target: 50 },
{ duration: '10m', target: 200 },
{ duration: '2m', target: 0 }
],
};
export default function () {
http.get('https://tu-sitio.com/');
sleep(1);
}
