Plan de Benchmarking
ℹ️ Nota: Este documento define qué medir, cuándo medir, y qué señales indican la necesidad de escalar. No se están ejecutando cargas destructivas ahora — este es un plan de medición.
Webhook Ingestion
| Campo | Valor |
|---|---|
| Métrica | Webhooks/segundo por canal |
| Objetivo | 1,000 webhooks/segundo sostenido |
| Medición | Webhooks batch de WhatsApp, eventos de páginas de Facebook |
| Herramienta | k6 o vegeta para load testing |
| Cuándo | Antes del lanzamiento de V1 |
Metodología:
- Simular carga de webhooks de múltiples canales simultáneamente
- Medir latencia de procesamiento desde receipt hasta persistencia
- Verificar no pérdida de webhooks bajo carga
- Monitorear uso de CPU, memoria, y conexiones de base de datos
Message Throughput
| Campo | Valor |
|---|---|
| Métrica | Mensajes/segundo (entrantes + salientes) |
| Objetivo | 500 mensajes/segundo sostenido |
| Medición | Latencia end-to-end desde receipt del webhook hasta delivery al agente |
| Herramienta | k6 con scripts personalizados |
| Cuándo | Antes del lanzamiento de V1 |
Metodología:
- Medir latencia en cada punto del pipeline: webhook → procesamiento → WebSocket → agente
- Verificar orden de mensajes bajo carga concurrente
- Monitorear degradación de latencia con carga creciente
- Establecer baseline de latencia en condiciones normales
Concurrent Conversations
| Campo | Valor |
|---|---|
| Métrica | Conversaciones activas por tenant, total |
| Objetivo | 10,000 conversaciones concurrentes |
| Medición | Uso de memoria, conexiones de base de datos, conexiones WebSocket |
| Herramienta | k6 + monitoreo de infraestructura |
| Cuándo | Antes del lanzamiento de V1 |
Metodología:
- Simular conversaciones activas con mensajes intermitentes
- Medir escalabilidad de memoria por conversación activa
- Verificar pool de conexiones de BD bajo carga
- Monitorear degradación por número de conexiones WebSocket
WebSocket Connections
| Campo | Valor |
|---|---|
| Métrica | Conexiones WebSocket concurrentes |
| Objetivo | 5,000 conexiones concurrentes por nodo |
| Medición | Memoria por conexión, latencia de delivery de mensajes |
| Herramienta | Scripts personalizados con connections masivas |
| Cuándo | Antes del lanzamiento de MVP |
Metodología:
- Establecer conexiones masivas y mantenerlas activas
- Medir consumo de memoria por conexión
- Verificar latencia de broadcast de mensajes
- Probar reconexión automática y manejo de desconexiones
Concurrent Agents
| Campo | Valor |
|---|---|
| Métrica | Agentes logueados simultáneamente |
| Objetivo | 500 agentes concurrentes |
| Medición | Frecuencia de actualización de estado, precisión de presencia |
| Herramienta | Simulador de agentes |
| Cuándo | Antes del lanzamiento de V1 |
Metodología:
- Simular agentes con cambios de estado frecuentes
- Medir precisión de indicadores de presencia
- Verificar latencia de actualización de estado
- Probar comportamiento ante desconexiones masivas
Routing Latency
| Campo | Valor |
|---|---|
| Métrica | Tiempo desde receipt del mensaje hasta asignación al agente |
| Objetivo | < 100ms p95 |
| Medición | Timestamps de eventos, tracing end-to-end |
| Herramienta | Instrumentación de código +istributed tracing |
| Cuándo | Antes del lanzamiento de V1 |
Metodología:
- Instrumentar pipeline con timestamps en cada paso
- Medir latencia del algoritmo de enrutamiento
- Verificar impacto de reglas complejas de enrutamiento
- Establecer baseline con diferentes volúmenes de carga
Database Growth
| Campo | Valor |
|---|---|
| Métrica | GB/mes, filas/día |
| Objetivo | Modelo de crecimiento predecible |
| Medición | Conversaciones, mensajes, contactos, grabaciones |
| Herramienta | Monitoreo de PostgreSQL |
| Cuándo | Mensual después del lanzamiento |
Metodología:
- Establecer baseline de crecimiento por tipo de dato
- Proyectar crecimiento a 6, 12, 24 meses
- Identificar retención de datos que impacta rendimiento
- Planificar particionamiento cuando sea necesario
Search Performance
| Campo | Valor |
|---|---|
| Métrica | Latencia de queries de búsqueda |
| Objetivo | < 200ms p95 para búsqueda de contactos |
| Medición | Búsqueda full-text, queries con filtros |
| Herramienta | Queries de prueba con datos representativos |
| Cuándo | Antes del lanzamiento de V1 |
Metodología:
- Poblar base de datos con 100K+ contactos de prueba
- Medir latencia de diferentes tipos de búsqueda
- Verificar impacto de índices en rendimiento
- Probar búsqueda con acentos y caracteres especiales (español/portugués)
Media Processing
| Campo | Valor |
|---|---|
| Métrica | Tiempo de procesamiento de imagen/video/audio |
| Objetivo | < 2 segundos para optimización de imagen |
| Medición | Tiempo desde upload hasta storage disponible |
| Herramienta | Tests de procesamiento de medios |
| Cuándo | Antes del lanzamiento de V1 |
Metodología:
- Procesar diferentes formatos y tamaños de archivo
- Medir tiempo de conversión y optimización
- Verificar calidad de salida
- Monitorear uso de CPU durante procesamiento
Campaign Throughput
| Campo | Valor |
|---|---|
| Métrica | Contactos procesados/hora |
| Objetivo | 10,000 contactos/hora por campaña |
| Medición | Pacing del dialer, intentos de llamada |
| Herramienta | Simulación de campaña con datos de prueba |
| Cuándo | Antes del lanzamiento de V2 |
Metodología:
- Configurar campaña con 10K+ contactos
- Medir velocidad de procesamiento real
- Verificar pacing del dialer predictivo
- Monitorear tasa de答(answer) vs. no answer
Reporting
| Campo | Valor |
|---|---|
| Métrica | Tiempo de generación de reportes |
| Objetivo | < 5 segundos para reportes estándar |
| Medición | Tiempo de ejecución de queries, agregación |
| Herramienta | Queries de reportes con datos representativos |
| Cuándo | Antes del lanzamiento de V1 |
Metodología:
- Generar reportes con diferentes volúmenes de datos
- Medir tiempo de query y procesamiento
- Identificar queries lentas para optimización
- Verificar impacto de indexes en rendimiento
Concurrent Calls
| Campo | Valor |
|---|---|
| Métrica | Llamadas de voz simultáneas |
| Objetivo | 200 llamadas concurrentes por nodo Asterisk |
| Medición | Conteo de canales Asterisk, streams RTP |
| Herramienta | Monitoreo de Asterisk + llamadas simuladas |
| Cuándo | Antes del lanzamiento de V1 |
Metodología:
- Establecer llamadas concurrentes de prueba
- Medir uso de recursos de Asterisk
- Verificar calidad de audio bajo carga
- Monitorear latencia de llamadas
Dialer Throughput
| Campo | Valor |
|---|---|
| Métrica | Intentos de llamada/segundo |
| Objetivo | 20 llamadas/segundo (configurable) |
| Medición | Tasa de éxito de ARI originate, precisión de pacing |
| Herramienta | Simulación de dialer con datos de prueba |
| Cuándo | Antes del lanzamiento de V2 |
Metodología:
- Configurar dialer con diferentes rates objetivo
- Medir precisión del pacing real vs. configurado
- Verificar manejo de contestación y no contestación
- Monitorear comportamiento ante variaciones de carga
Señales de Escalamiento
| Señal | Umbral | Acción |
|---|---|---|
| CPU > 70% sostenido | Crítico | Escalar horizontalmente |
| Memoria > 80% | Crítico | Investigar fugas o escalar |
| Conexiones DB > 80% del pool | Alto | Agregar read replicas |
| Conexiones WebSocket > 80% capacidad | Alto | Agregar nodos |
| Profundidad de cola de mensajes creciente | Medio | Agregar workers |
| Tiempo de respuesta > SLA | Crítico | Investigar y escalar |
Evitación de Optimización Prematura
�️ Advertencia: NO optimizar para 1M de conversaciones cuando se están ejecutando 10K.
| Evitar | Cuándo optimizar |
|---|---|
| Implementar cache | Cuando el profiling muestre necesidad |
| Shardear la base de datos | Cuando se alcancen los límites del nodo único |
| Agregar message broker | Cuando se necesite comunicación entre procesos |
| Optimizar queries | Cuando las métricas muestren lentitud |
| Agregar CDN | Cuando el tráfico de assets lo justifique |
Principios de medición
- Medir primero, optimizar después: Nunca optimizar sin datos
- Baseline antes de cambios: Establecer métricas antes de implementar optimizaciones
- Monitoreo continuo: Las métricas deben estar disponibles en producción
- Alertas configuradas: Umbrales claros para acciones de escalamiento
- Documentar resultados: Cada benchmark debe ser documentado y repetible
Herramientas Recomendadas
| Herramienta | Uso | Licencia |
|---|---|---|
| k6 | Load testing HTTP/WebSocket | Open source |
| vegeta | HTTP load testing | Open source |
| pgBadger | Análisis de logs PostgreSQL | Open source |
| Grafana | Dashboard de métricas | Open source |
| Prometheus | Recolección de métricas | Open source |
| Jaeger | Distributed tracing | Open source |
| Asterisk CLI | Monitoreo de llamadas | Incluido con Asterisk |
💡 Consejo: Todas las herramientas de monitoreo y testing deben estar configuradas antes del primer benchmark. El primer benchmark se ejecuta con datos mínimos para establecer baseline, no con carga máxima.