Los servidores de streaming de música autohospedados suelen experimentar aumentos no lineales de latencia durante paginaciones profundas y agregaciones complejas en colecciones masivas. Para documentar el comportamiento operativo real, evaluamos los tiempos de respuesta en las rutas de lectura Subsonic de PureStream mediante un conjunto de datos de prueba con 500.000 pistas.
Alcance de la prueba y construcción del catálogo
Las bibliotecas personales de coleccionistas alcanzan con frecuencia cientos de miles de pistas. Los puntos de entrada más utilizados en el protocolo Subsonic (enumeración search3, exploración con getMusicDirectory y listados de álbumes en getAlbumList2) muestran patrones de coste variables según el volumen de datos. Ciertas rutas aprovechan índices de cobertura, mientras que otras requieren deduplicación en la tabla completa. En esta fase se completaron las siguientes tareas:
- [x] Generación de un catálogo de prueba de 500.000 registros (~42.000 álbumes, 2.000 artistas y 100 géneros) mediante el flujo habitual de migraciones, creando una base SQLite idéntica a producción
- [x] Incorporación de un índice de cobertura para consultas por género y registro en la validación de esquemas para evitar desajustes
- [x] Registro de métricas P50 y P95 en 14 rutas de lectura clave para establecer una línea base de rendimiento
Métricas de las principales rutas de lectura
| Punto de entrada | 100k | 500k | Evaluación |
|---|---|---|---|
| search3 enumeración principal | 53µs | 69µs | Estable |
| search3 página profunda (offset=250k) | — | 25ms | Estable |
| getMusicDirectory página única | 1.3ms | 1.4ms | Estable |
| getAlbumList2 tres modos de paginación | 8–82ms | 86–333µs | Estable |
| getSongsByGenre | no medido | 113µs | Índice efectivo |
| FTS búsqueda de texto | 24.8ms | 137ms | Crecimiento lineal |
| getArtists deduplicación | 3.4ms | 543ms | Carga de agregación |
| getGenres agregación | no medido | 600ms | Dentro de límites |
| Directorio individual extenso (página profunda) | — | 734ms | Caso de borde |
Observaciones principales:
- Enumeración principal (69 µs): La consulta estándar de search3 se mantiene en el rango de microsegundos con 500.000 filas gracias a un índice de cobertura parcial sobre registros válidos, protegiendo las lecturas de los escaneos concurrentes en disco.
- Paginación profunda (25 ms): Obtener una página con un desplazamiento de 250.000 pistas requiere 25 milisegundos, preservando una navegación ágil en milisegundos.
- Filtrado por género (113 µs): El nuevo índice transforma el plan de ejecución de un escaneo completo a una búsqueda indexada, reduciendo de forma sustancial el tiempo de proceso.
Análisis de puntos de alta demanda de cálculo
Las mediciones identificaron dos escenarios de agregación con mayor consumo computacional:
- getArtists deduplicación (543 ms): La unión de artistas principales y participantes exige un recorrido completo de la tabla. Con 500.000 pistas, el tiempo se mantiene por debajo de un segundo y permanece en monitorización activa.
- getGenres agregación (600 ms): El recuento de álbumes únicos mediante
COUNT(DISTINCT album)requiere unos 600 milisegundos en la escala de 500.000 pistas.
Entregables de la iteración
- [x] Línea base completa de rendimiento P50/P95 para 14 puntos de lectura en 500.000 pistas
- [x] Despliegue del índice de lectura para géneros con validación de esquemas y pruebas de planes de ejecución
- [x] Cuantificación de los puntos de esfuerzo en consultas de agregación para orientar mejoras posteriores
Próximos pasos
- [ ] Optimización de paginación: Implementación de navegación por cursores en endpoints sin parámetro de offset
- [ ] Consolidación de consultas de autenticación de sesión en streaming continuo