Configuración del Servidor ASGI - PRIORIDAD ALTA

IMPORTANTE: Esta configuración es crítica para la estabilidad de la aplicación, especialmente cuando se conectan decenas o centenas de dispositivos simultáneamente.

Fecha: 04-02-2026 Versión: v6.4.1

Resumen Ejecutivo

La aplicación CreaRack Pro usa WebSockets para:

Network Observatory: Monitoreo en tiempo real de dispositivos
Terminal SSH: Conexiones interactivas a equipos de red
Alertas: Notificaciones push en tiempo real

Cuando se monitorean muchos dispositivos simultáneamente, el consumo de memoria puede crecer significativamente. Esta guía documenta la configuración óptima.

1. Servidor ASGI: Daphne (Recomendado)

Por qué Daphne y NO Uvicorn

Aspecto	Uvicorn	Daphne
Consumo memoria	650-800 MB	200-300 MB
Estabilidad WebSocket	Problemas de timeout	Estable
Origen	Genérico ASGI	Oficial Django Channels
WebSocket keepalive	Requiere configuración manual	Optimizado por defecto

Decisión (04-02-2026): Se migró de Uvicorn a Daphne debido a:

Caídas frecuentes por “keepalive ping timeout”
Consumo excesivo de memoria (650+ MB)
Inestabilidad con múltiples conexiones WebSocket

Configuración en compose.yml

web:
  command: daphne -b 0.0.0.0 -p 8000 --proxy-headers config.asgi:application
  restart: unless-stopped
  deploy:
    resources:
      limits:
        memory: 512M      # Límite duro - Docker reinicia si se excede
      reservations:
        memory: 256M      # Mínimo garantizado

Opciones de Daphne

Opción	Descripción
`-b 0.0.0.0`	Escuchar en todas las interfaces
`-p 8000`	Puerto
`--proxy-headers`	Respetar headers X-Forwarded-* de proxy/load balancer
`-v 2`	Verbosidad (opcional, para debug)

2. Channel Layer (Redis/Valkey)

Configuración Óptima

# config/settings/dev.py (o production.py)
CHANNEL_LAYERS = {
    "default": {
        "BACKEND": "channels_redis.core.RedisChannelLayer",
        "CONFIG": {
            "hosts": [(os.getenv("REDIS_HOST", "cache"), 6379)],
            "capacity": 1500,  # Máximo mensajes en cola por canal
            "expiry": 60,      # Mensajes expiran en 60 segundos
        },
    },
}

Por qué es importante

Parámetro	Sin configurar	Configurado	Impacto
`capacity`	Ilimitado	1500	Evita memory leak por mensajes acumulados
`expiry`	Ilimitado	60s	Limpia mensajes huérfanos automáticamente

Escenario problemático sin configurar:

100 dispositivos × 6 métricas/dispositivo × 1 mensaje/segundo = 600 mensajes/segundo
Si un cliente se desconecta sin limpiar, los mensajes se acumulan indefinidamente
Resultado: Memory leak → Crash

3. Límites de Memoria Docker

Configuración

deploy:
  resources:
    limits:
      memory: 512M    # CRÍTICO: Límite máximo
    reservations:
      memory: 256M    # Mínimo reservado

Comportamiento

Situación	Acción de Docker
Memoria < 512M	Normal
Memoria = 512M	Docker mata el proceso (OOM)
`restart: unless-stopped`	Docker reinicia automáticamente

Esto actúa como Supervisord: Si hay memory leak, el contenedor se reinicia automáticamente en lugar de quedarse colgado.

4. Estimación de Recursos por Escala

Memoria estimada por número de dispositivos

Dispositivos	Conexiones WS	Memoria estimada	Recomendación
1-10	~10	150-200 MB	512M límite
10-50	~50	200-350 MB	512M límite
50-100	~100	350-500 MB	768M límite
100-500	~500	500-1000 MB	1.5G límite + workers

Para más de 100 dispositivos

Considerar:

Múltiples workers Daphne:

command: daphne -b 0.0.0.0 -p 8000 --proxy-headers -t 60 config.asgi:application

Horizontal scaling con load balancer
Separar servicios:
- Web app (HTTP) → Gunicorn
- WebSockets → Daphne dedicado

5. Monitoreo

VictoriaMetrics

Acceder a http://localhost:8428/vmui para monitorear métricas PromQL:

Memoria del contenedor web
Conexiones WebSocket activas
Request rate y latencia

Comandos útiles

# Ver memoria actual
docker stats crearack_web

# Ver logs en tiempo real
docker compose logs -f web

# Reiniciar si hay problemas
docker compose restart web

6. Troubleshooting

Síntoma: Aplicación cae sin error aparente

Causa probable: OOM (Out of Memory)

Verificar:

docker inspect crearack_web | grep -A5 "State"
# Buscar "OOMKilled": true

Solución: Aumentar límite de memoria o reducir dispositivos monitoreados.

Síntoma: WebSocket se desconecta frecuentemente

Causa probable: Timeout de keepalive

Solución: Ya resuelto con Daphne. Si persiste, verificar:

Proxy/Load balancer timeout settings
Firewall no bloqueando conexiones largas

Síntoma: Memoria crece constantemente

Causa probable: Channel Layer sin límites

Solución: Verificar configuración de capacity y expiry.

7. Historial de Cambios

Fecha	Cambio	Motivo
04-02-2026	Migración Uvicorn → Daphne	Inestabilidad, memoria excesiva
04-02-2026	Añadido capacity/expiry a Channel Layer	Prevenir memory leak
04-02-2026	Límite memoria Docker 512M	Auto-recovery en OOM

Mantenido por: Equipo CreaRack

Véase también

[[decision—20260201—conn-max-age-daphne]] — ADR CONN_MAX_AGE con Daphne
[[crearack-tech—guides—production-deployment]] — deploy en producción Hetzner
[[crearack-tech—guides—docker-guide]] — guía de Docker Compose
[[crearack-tech—admin—dokploy-internals]] — internals de Dokploy
[[crearack-tech—admin—dokploy-guide]] — guía de Dokploy
[[crearack-tech—guides—deploy-checklist]] — checklist de deploy Golden Path