# Pruebas de Rendimiento y Resultados de Benchmark 📊⚡
Para garantizar la viabilidad del CLI `bgustscraper` como un agente local ligero y de bajo consumo en entornos host o micro-servicios, implementamos un completo motor de telemetría y benchmark integrado (`src/benchmark.rs`).
Este benchmark evalúa de forma científica el tiempo de respuesta y el **consumo pico real de memoria RAM** del ecosistema completo en tres escenarios típicos de raspado e ingesta de datos.
---
## 🔬 Metodología de Medición
Medir el consumo de RAM de una herramienta de scraping moderna es complejo debido a que Chromium y Node.js levantan múltiples subprocesos aislados en segundo plano. Sumar únicamente el consumo del ejecutable de Rust ignoraría el 95% del uso real del sistema.
### ¿Cómo lo resolvemos?
`bgustscraper` implementa un buscador recursivo de árbol de procesos nativo en Rust:
1. Obtiene el PID (*Process Identifier*) del ejecutable actual en Rust.
2. Escanea recursivamente la tabla de procesos del sistema operativo identificando todos los hijos, nietos y procesos descendientes de Node.js, Playwright y Chromium.
3. Utiliza un `HashSet` para deduplicar los PIDs recopilados y evitar la doble contabilidad que producen las librerías compartidas mapeadas en memoria por los subprocesos de Chromium.
4. Suma los bytes de memoria residente y calcula el consumo pico exacto del ecosistema.
---
## 📈 Resultados del Benchmark
A continuación se exponen las métricas oficiales arrojadas por la suite de pruebas al ejecutarse en un entorno CPU comercial estándar de Linux:
### Resumen Comparativo de Recursos:
| **Escenario 1: Sintáctico Puro** | **3.84s** | **8,953.41** | Raspado estático tradicional, extracción de enlaces directos. Sin NLP ni ONNX. |
| **Escenario 2: Semántico Completo** | **19.61s** | **109,397.24** | Flujo completo en caliente: Navegación, embeddings vectoriales (MiniLM), clustering K-Means en Rust y estructuración generativa (Qwen-0.5B ONNX). |
| **Escenario 3: Caché Embebida** | **10.39s** | **73,165.75** | Recuperación instantánea sin red desde `redb`. Compresión y estructuración con Qwen-0.5B ONNX en CPU. |
---
## 🔍 Análisis Detallado de los Escenarios
### Escenario 1: Sintáctico Puro (Tradicional HTML/Regex)
* **Comportamiento:** Levanta Chromium en modo oculto (*headless*), navega, obtiene el DOM y extrae los enlaces a través del selector sintáctico nativo de Rust.
* **Diagnóstico:** Es extremadamente veloz. Al no ejecutar inferencia local de machine learning, la RAM consumida es únicamente la huella base del navegador Chromium activo.
### Escenario 2: Semántico Completo (Modelos ONNX Locales)
* **Comportamiento:** Levanta Chromium, extrae el texto, genera embeddings densos de 384 dimensiones para cada oración con `all-MiniLM-L6-v2`, ejecuta el agrupamiento K-Means de 12 clusters en Rust y ejecuta la inferencia generativa estructurada de `Qwen2.5-0.5B-Instruct` cuantizado en precisión Q4.
* **Diagnóstico:** Representa la carga máxima del sistema. El tiempo es de 19.61 segundos debido al coste de inicialización del runtime de ONNX por primera vez y la generación secuencial de tokens del LLM en CPU. Es el escenario ideal para el raspado inicial profundo.
### Escenario 3: Caché Embebida (Lectura persistente en `redb`)
* **Comportamiento:** Cero conexiones de red. El CLI detecta que la página ya está en la caché local transaccional `redb`. Lee el Markdown y los embeddings almacenados, ejecuta el clustering K-Means en Rust y alimenta directamente la extracción estructurada del LLM.
* **Diagnóstico:** **El tiempo de respuesta se reduce casi a la mitad (10.39s)** y el consumo de RAM pico disminuye significativamente al no requerir la ejecución en segundo plano del navegador web Chromium (Playwright).
---
## 💡 Conclusión y Recomendación de Despliegue
1. **Eficiencia en Caché:** Los datos demuestran que el uso inteligente de la caché transaccional embebida (`redb`) es crítico: ahorra ancho de banda, evita bloqueos de IP y reduce drásticamente el consumo de CPU y RAM.
2. **CPU-Friendly:** Al mantenerse por debajo de los límites lógicos de memoria y CPU, `bgustscraper` puede ser desplegado de forma segura en contenedores Docker de un solo núcleo de CPU o servidores VPS económicos sin necesidad de incurrir en costes de GPUs dedicadas.