Área: API / Performance
Severidad: Alta
Puntaje actual: 4/10 | Potencial: 8/10
---
Síntoma
El endpoint
/api/music-score/user-fav-music-score recibe 1 request GET por segundo mientras cualquier pantalla está abierta. En una sesión de 46 segundos se contaron 46 requests a este único endpoint.Evidencia cuantitativa
eval-api.mjs — CDP Network analysis:
Total API requests: 51
user-fav-music-score: 46x (90%)
⚠ H3: 46 requests in 45.6s (polling every 1.0s)
eval-console.mjs — Confirmación independiente:
API calls: 50
46x https://web2.faristol.net/api/music-score/user-fav-music-score
2x https://web2.faristol.net/api/music-score/allmusic
1x https://web2.faristol.net/api/auth/login
1x https://web2.faristol.net/api/music-score/get/21
Impacto
Factor | Detalle --------|--------- Rate limit | Servidor configurado a 60 req/min/IP. Con 46 reqs en 46s = ~60 req/min. Un solo usuario satura su propio límite Escalabilidad | Con 60 usuarios concurrentes = 60 req/s a este endpoint. Sin cache, pega a DB cada vez Ancho de banda | ~1KB por response × 46 reqs × 60 usuarios × 60 mins = ~165MB/hora innecesarios UX | Sin beneficio visible para el usuario. Los favoritos no cambian cada segundo Causa raíz
Flutter Web app ejecuta
Timer.periodic(Duration(seconds: 1)) para refrescar el estado de favoritos. No hay throttling, ni cache, ni websocket. El polling continúa incluso cuando la app está en background (determinado por análisis de network timing continuo).Reproducción
export DISPLAY=:99
cd /home/admin/fluttwebfaris
node eval-api.mjs
# Observar: ~46 requests en ~46s
Fix sugerido
1. Aumentar intervalo a 5-10s (reducción 80-90% de tráfico)
2. Usar WebSocket para push de cambios de favoritos
3. Cache local del estado de favoritos, solo refrescar cuando el usuario abre Favorites tab
4. Rate limit endpoint específico a 12 req/min (1/5s) en backend
Tiempo estimado de fix
2-4h (cambio intervalo + cache local) / 8-16h (WebSocket)
Referencias
•
eval-api.mjs — CDP monitoring script•
eval-console.mjs — HTTP request analysis•
NOTAS-ERRORES.md línea 40-56