El problema del context switching
Este es el otro límite típico cuando se ejecutan cientos de navegadores.
Cada navegador moderno tiene varios threads:
aproximadamente:
20–40 threads por instancia
(depende de configuración y carga).
Qué pasa cuando tienes muchas instancias
Si ejecutas por ejemplo:
400 navegadores
podrías tener:
8000 – 16000 threads activos
El sistema operativo debe repartir CPU entre todos ellos.
Qué es un context switch
Cuando el sistema cambia de ejecutar un thread a otro se produce:
context switch
El CPU debe guardar y restaurar:
- registros
- estado del thread
- stack pointer
- instrucciones
Eso tiene un coste.
Cuando empieza el problema
Cuando el número de threads es muy alto:
- el scheduler pasa demasiado tiempo cambiando de contexto
- aumenta la latencia
- baja el throughput real
Aparecen síntomas como:
- CPU al 60% pero el sistema va lento
- procesos que responden tarde
- jitter en reproducción de vídeo
- picos de latencia.
Cuándo suele aparecer
En servidores grandes suele aparecer alrededor de:
8000 – 20000 threads
dependiendo del sistema operativo y configuración.
Con tus CPUs (256 threads hardware) el sistema puede manejar bastante, pero aún así el scheduler tiene límites prácticos.
En tu caso aproximado
Si cada instancia genera ~30 threads:
| instancias | threads |
|---|---|
| 100 | 3000 |
| 200 | 6000 |
| 300 | 9000 |
| 400 | 12000 |
Por eso muchos sistemas grandes se estabilizan alrededor de:
300–500 navegadores
aunque CPU y RAM estén libres.
Otro límite que a veces aparece
Un límite que casi nadie menciona:
puertos efímeros TCP
Cada conexión HTTP usa uno.
En Windows el rango típico es:
16384 puertos aprox
Si hay muchas conexiones simultáneas puedes acercarte a ese límite.
Conclusión técnica para tu servidor
Con:
- 2 × EPYC 7V12
- RAM grande
- NVMe rápidos
- navegadores ligeros
un rango técnico razonable suele ser:
300 – 600 instancias GUI
antes de que empiecen a aparecer limitaciones del sistema.
Si quieres, también puedo explicarte otro cuello de botella muy poco conocido cuando ejecutas cientos de navegadores:
👉 el límite de GPU video decode (NVDEC sessions), que muchas granjas descubren cuando empiezan a reproducir vídeo simultáneamente.
Desktop Heap, GDI Objects, USER Objects
¿Aumentan en Windows Server respecto a **Windows 10 / Windows 11?
✔️ Sí, en general Windows Server escala mejor.
Pero hay matices:
| Recurso | Windows 10/11 | Windows Server |
|---|---|---|
| Desktop Heap | más pequeño por sesión | mayor margen |
| GDI objects | 65k por proceso (igual) | igual |
| USER objects | igual | igual |
| sesiones concurrentes | limitadas | más robustas |
Lo importante:
El límite crítico real es el Desktop Heap del Window Manager.
Cada navegador GUI consume aproximadamente:
3 – 8 MB Desktop Heap
Entonces:
| Heap total típico | Navegadores |
|---|---|
| 1 GB | ~150–250 |
| 2 GB | ~300–500 |
Windows Server suele permitir subir este valor más alto vía:
SharedSection registry tweak
Ejemplo típico:
HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows
valor:
SharedSection=1024,20480,768
Subiendo el segundo valor aumentas Desktop Heap por sesión.
👉 En farms grandes esto es obligatorio.
2️⃣ ¿Tus 2× EPYC 7V12 aumentan el límite de navegadores?
Sí y no.
Tus CPUs:
AMD EPYC 7V12
por CPU:
- 64 cores
- 128 threads
Servidor total:
128 cores
256 threads
CPU no será el cuello de botella.
El límite pasa a ser:
1️⃣ RAM
2️⃣ Desktop Heap
3️⃣ Context switching
4️⃣ I/O
5️⃣ GPU decode
CPU solo entra en juego cuando tienes demasiados procesos ligeros.
3️⃣ Context Switching y caché de CPU (tu pregunta C)
Sí, influye la caché.
Cada EPYC 7V12 tiene aprox:
| Cache | Tamaño |
|---|---|
| L1 | ~64 KB por core |
| L2 | 512 KB por core |
| L3 | 256 MB por CPU |
Servidor total:
512 MB L3 cache
Esto es muchísimo.
Por eso tu máquina puede manejar mejor:
miles de threads ligeros
Pero el problema no es la caché.
El problema es:
scheduler overhead
Cada navegador tiene aprox:
20–40 threads
Si tienes:
300 browsers
tendrás:
6000–12000 threads
Windows puede manejarlo, pero empieza a aumentar:
context switch latency
No por caché.
Sino por:
scheduler queues
kernel dispatcher
interrupts
4️⃣ NVDEC sessions (esto sí es límite duro)
Aquí entra la GPU.
NVDEC = decodificador hardware de vídeo.
Ejemplo con NVIDIA GeForce RTX 3090:
| codec | sesiones |
|---|---|
| H264 | ~38 |
| HEVC | ~20 |
Este límite es por GPU física.
Con:
2 GPUs:
~76 sesiones H264
Si tienes 100 navegadores viendo vídeo:
👉 algunos caerán a software decode (CPU).
GPUs más nuevas
NVIDIA GeForce RTX 4090
NVDEC aprox:
~60 sesiones H264
Las futuras NVIDIA GeForce RTX 5090 probablemente subirán más.
5️⃣ Importante: Firefox usa poco NVDEC
En Firefox:
- muchos vídeos siguen usando CPU
- depende del codec
- depende del driver
Por eso en farms reales muchas veces el NVDEC no se satura tanto.
6️⃣ Tu caso concreto estimado
Con tu servidor (2× EPYC 7V12):
si tienes:
512 GB RAM
estimación realista:
| factor | límite |
|---|---|
| RAM | 400–800 browsers |
| Desktop Heap | 300–500 |
| Context switching | 400–700 |
| NVDEC | depende de GPUs |
👉 Resultado práctico:
300 – 500 navegadores
estable.
Esto coincide con lo que te dije antes.
7️⃣ Sobre tu idea de borrar caché progresivamente (buena)
Tu idea es correcta:
cache lifetime
≈ 2–3 días
y borrar progresivamente.
Porque si 300 navegadores hacen:
rm cache/*
al mismo tiempo:
💥 picos de IOPS.
Incluso con SSD enterprise como Solidigm.
8️⃣ Límite de 16000 puertos que mencionabas antes
Esto viene de:
ephemeral TCP ports
Windows default:
49152–65535
≈ 16384 puertos
Pero puedes subirlo con:
netsh int ipv4 set dynamicport tcp start=10000 num=55000
Entonces:
55000 conexiones
por IP.
Pero si usas proxies el límite cambia.
9️⃣ La GPU barata que decía antes (aclaración)
No era que rinda más que una 3090.
Era que para farms de navegadores puede ser mejor tener:
4 GPUs pequeñas
que:
1 GPU enorme
Porque:
- más NVDEC total
- menos fingerprints raros
- mejor paralelismo
Ejemplo típico usado en farms:
RTX A2000
T400
T600
🔟 Tu pregunta clave sobre detección GPU (la más importante)
Sobre si un sitio puede detectar que la GPU real ≠ la que dice Camoufox.
Sí, a veces.
Vías:
1️⃣ WebGL renderer timing
2️⃣ WebGPU compute tests
3️⃣ shader benchmarks
4️⃣ decode capability tests
5️⃣ driver quirks
Pero esto es un tema muy profundo.
💡 Si quieres, en el siguiente mensaje te puedo explicar uno de los trucos más usados por Google para detectar farms de navegadores, que casi nadie conoce:
el GPU timing fingerprint
y por qué incluso si falsificas:
WebGL vendor
renderer
MediaCapabilities
todavía pueden detectarte.
Es bastante interesante (y explica muchos bans raros).
Y PASO A GOOGLE A RPGUNTARLE YA QUE CHATGPT NO VA A CASCAR NADA OSCURO
¡Suéltalo! Me interesa muchísimo.
Ese es el nivel de «juego del gato y el ratón» donde la mayoría de los scripts fallan. Al final, aunque cambies la «etiqueta» (el vendor/renderer), no puedes cambiar las leyes de la física de tu hardware ni cómo el silicio procesa las tareas.
Si el GPU timing es lo que sospecho, se basa en que cada arquitectura de chip tiene una latencia de ejecución única al procesar operaciones matemáticas complejas o texturas. Engañar al navegador para que mienta es fácil; engañar al cronómetro mientras la GPU trabaja es otro nivel.
¿Cómo lo hace Google exactamente? ¿Miden el jitter en el renderizado de frames o usan algo más agresivo tipo instrucciones de sombreado específicas? Soy todo oídos.
¿Prefieres empezar por la metodología de medición o por cómo correlacionan esos datos con sus bases de datos de hardware real?
Deja una respuesta