Procesos concurrentes: el límite invisible que tira tu web justo cuando tienes visitas
Publicado el 24 de julio de 2026 · Actualizado el 5 de agosto de 2026
Por Rubén Ortega · 12 años en soporte técnico y preventa de empresas de hosting (Abansys, Arsys, Nominalia) · Declaración de vínculos
📌 Datos clave
- Qué es
- Peticiones que tu cuenta puede atender a la vez
- Cuándo se ocupa uno
- En cada carga de página que no venga de caché
- Error asociado
- 508 Resource Limit Is Reached
- Señal característica
- Falla en horas punta, va bien de madrugada
- Lo que más lo alivia
- Caché de página
Respuesta rápida
Los procesos concurrentes son cuántas peticiones puede atender tu cuenta al mismo tiempo. No cuántas al día ni al mes: al mismo tiempo.
Es el límite que explica el caso que desconcierta a todo el mundo: una web que aguanta perfectamente 2.000 visitas repartidas por el día y se cae con 30 personas entrando a la vez tras enviar una newsletter.
Y es, con diferencia, el límite peor comunicado del sector. Casi ningún proveedor lo pone en la página de precios, y la métrica que sí anuncian —«hasta X visitas al mes»— no dice nada sobre él.
Cómo se agota
Cada vez que alguien pide una página que no está en caché, ocurre esto:
- Se ocupa un proceso PHP
- Ese proceso ejecuta el código y consulta la base de datos
- Genera el HTML y responde
- El proceso se libera
La clave está en cuánto dura el paso 2. Si tu web tarda 300 ms en generarse, cada proceso se libera enseguida y con 20 procesos atiendes mucha gente. Si tarda 3 segundos, cada visitante retiene su proceso diez veces más, y con 20 procesos te saturas con muchísimos menos visitantes.
Por eso una web lenta se cae antes que una rápida con el mismo tráfico: no es solo que vaya despacio, es que retiene el cupo más tiempo.
Cuánta gente aguantas de verdad
Esta es la cuenta que nadie publica y que explica por qué dos webs con el mismo plan se comportan distinto. Con 20 procesos disponibles:
| Tu web tarda en generarse | Visitas simultáneas que aguantas | Visitas/hora aproximadas |
|---|---|---|
| 200 ms | ~100 | ~360.000 |
| 500 ms | ~40 | ~144.000 |
| 1 s | ~20 | ~72.000 |
| 3 s | ~7 | ~24.000 |
| 5 s | ~4 | ~14.000 |
La cuenta es sencilla: procesos ÷ tiempo de generación = peticiones por segundo. Y la conclusión importa: bajar el tiempo de generación de 1 s a 200 ms multiplica por cinco tu capacidad sin cambiar de plan. Es más barato optimizar que subir de plan, y además es lo que hay que hacer antes.
Estas cifras asumen que todas las visitas generan página. Con caché activa, la mayoría no ocupa proceso, y por eso la caché es lo primero.
El error que verás
Cuando no queda cupo, el servidor devuelve un 508 Resource Limit Is Reached. En algunas configuraciones sale un 503 o directamente un tiempo de espera agotado.
Lo que hace que cueste tanto diagnosticarlo:
- Es intermitente. Unos visitantes lo ven y otros no, en el mismo instante
- Se arregla solo. Cuando baja el tráfico, vuelve a funcionar
- No hay nada roto. Revisas la web, va perfecta, y concluyes que fue cosa de un momento
- Aparece en el peor momento: cuando te llega tráfico
Muchas personas viven con esto durante meses sin saber que existe.
Cómo saber si es tu caso
En el panel de control. Busca la gráfica de uso de recursos: en cPanel está en Resource Usage, en Plesk dentro del uso de la suscripción. Ahí se ve si has tocado el tope y a qué hora.
Por el patrón horario. Si la web va bien de madrugada y falla entre las 18:00 y las 22:00, es un problema de concurrencia casi seguro.
Correlacionando con lo que hiciste. ¿Enviaste una newsletter? ¿Publicaste en redes? ¿Salió un artículo tuyo en algún sitio? Los picos de concurrencia tienen causa.
Preguntando al soporte con una pregunta que obliga a mirar:
«¿Podéis confirmar si entre las 19:10 y las 19:25 del 23 de julio mi cuenta alcanzó el límite de procesos concurrentes?»
Esa pregunta no se puede responder con el guion. Más sobre esto en qué pasa cuando abres un ticket.
Qué hacer
En orden de rentabilidad:
1. Activa caché de página. Es lo que más alivia, y con diferencia. Una visita servida desde caché apenas ocupa proceso: el servidor entrega un fichero ya montado. En una web informativa, esto puede reducir el consumo un 90 %.
2. Reduce el tiempo de generación. Cada milisegundo que tarda tu web es tiempo que retiene un proceso. Los plugins que consultan la base de datos en cada carga son los sospechosos habituales: qué es el TTFB.
3. Bloquea el tráfico basura. Bots que rastrean sin control consumen procesos igual que las personas. Un rastreador agresivo puede comerse tu cupo sin traerte una sola visita.
4. Revisa las tareas programadas. Un cron pesado ejecutándose en hora punta compite con tus visitantes por los mismos procesos. Muévelo de madrugada.
5. Sube de plan, si nada de lo anterior basta. Pero hazlo después de los cuatro primeros: subir de plan sin optimizar es pagar más por el mismo problema, solo que más tarde.
Para ver dónde estás ahora mismo, la gráfica del panel lo dice: cómo leer el consumo de recursos. Y si lo que anuncia tu plan son «visitas ilimitadas», conviene saber qué significa eso de verdad.
Si ya has hecho los cuatro primeros pasos y sigues tocando el tope, el plan se te ha quedado pequeño de verdad. Raiola es el proveedor con el que tenemos programa; su precio es plano, así que subir de plan no te añade una sorpresa al año siguiente.
Enlace de afiliado: si contratas, cobramos una comisión de cada pago que hagas, también en las renovaciones. No te cuesta más.
Por qué esto importa el doble en una tienda
En una web informativa, la caché tapa casi todo. En una tienda no puede hacerlo: el carrito, «mi cuenta» y el proceso de pago no se cachean nunca, porque su contenido es distinto para cada persona.
Traducido: cada comprador ocupa un proceso durante toda su compra. Veinte personas comprando a la vez son veinte procesos ocupados durante minutos, no milisegundos.
Por eso el límite de procesos es el número que hay que preguntar antes de montar una tienda: por qué el carrito no se cachea.
Un caso concreto de esto es el límite de conexiones simultáneas a la base de datos, que produce un error propio: «Error al establecer una conexión con la base de datos».
Preguntas frecuentes
¿Qué son los procesos concurrentes?
El número máximo de peticiones que tu cuenta puede atender a la vez. Cada visitante que carga una página no cacheada ocupa uno mientras se genera.
¿Qué es el error 508?
El que devuelve el servidor cuando tu cuenta alcanza un límite de recursos, casi siempre este. No significa que tu web esté rota: significa que no había cupo libre.
¿Cómo sé si me estoy quedando sin procesos?
La señal más clara es que la web va bien de madrugada y falla en horas punta, con errores que unos visitantes ven y otros no.
¿Cuántos procesos necesito?
Depende de tu tráfico simultáneo y de lo que tarde tu web en generarse. No hay un número universal: por eso importa más el patrón horario que la cifra absoluta.
Guía general sobre el funcionamiento de los límites de concurrencia en alojamiento compartido. Los límites concretos de cada plan se publicarán cuando estén verificados.