Serviços de streaming de música autohospedados frequentemente enfrentam aumentos não lineares de latência em paginações profundas e agregações complexas com o crescimento das coleções. Para mapear com exatidão as características de funcionamento real, realizamos medições detalhadas nos fluxos de leitura Subsonic do PureStream com uma base de testes de 500.000 faixas.
Escopo dos testes e montagem dos dados
Coleções de entusiastas alcançam rotineiramente centenas de milhares de músicas. Os principais endpoints do protocolo Subsonic (enumeração search3, navegação via getMusicDirectory e listagens de álbuns em getAlbumList2) mostram perfis de custo distintos conforme o volume. Algumas rotas utilizam índices de cobertura, enquanto outras demandam deduplicação em tabela completa. Nesta rodada de testes, foram executadas as seguintes etapas:
- [x] Criação de um catálogo de testes com 500.000 registros (~42.000 álbuns, 2.000 artistas e 100 gêneros) usando o fluxo de migração para reproduzir um banco SQLite idêntico ao de produção
- [x] Implementação de índice de cobertura para consultas por gênero com verificação de esquema para evitar ausências de índice
- [x] Coleta de latências P50 e P95 em 14 caminhos de leitura essenciais para estabelecer a linha de base
Métricas dos principais fluxos de leitura
| Endpoint | 100k | 500k | Avaliação |
|---|---|---|---|
| search3 enumeração principal | 53µs | 69µs | Estável |
| search3 página profunda (offset=250k) | — | 25ms | Estável |
| getMusicDirectory página única | 1.3ms | 1.4ms | Estável |
| getAlbumList2 três modos de paginação | 8–82ms | 86–333µs | Estável |
| getSongsByGenre | não medido | 113µs | Índice eficaz |
| FTS busca de texto | 24.8ms | 137ms | Crescimento linear |
| getArtists deduplicação | 3.4ms | 543ms | Custo de agregação |
| getGenres agregação | não medido | 600ms | Dentro do esperado |
| Diretório único extenso (página profunda) | — | 734ms | Caso de borda |
Observações de destaque:
- Enumeração principal (69 µs): A consulta padrão do search3 permanece na faixa de microssegundos em 500.000 registros, beneficiando-se de um índice parcial que protege as leituras contra gravações concorrentes do escaneador.
- Paginação profunda (25 ms): Consultar uma página no deslocamento de 250.000 faixas consome 25 milissegundos, garantindo respostas ágeis em qualquer faixa de offset.
- Filtragem por gênero (113 µs): O novo índice de cobertura altera o plano de execução de uma varredura completa para uma busca indexada, acelerando sensivelmente a consulta.
Análise de gargalos computacionais
Os ensaios evidenciaram dois cenários de agregação com maior consumo de processamento:
- getArtists deduplicação (543 ms): A união de artistas principais e participantes exige varredura completa da tabela. Em 500.000 faixas, o tempo fica abaixo de um segundo e segue sob observação técnica.
- getGenres agregação (600 ms): A contagem de álbuns únicos via
COUNT(DISTINCT album)requer cerca de 600 milissegundos no patamar de 500.000 músicas.
Resultados entregues
- [x] Linha de base P50/P95 completa para 14 endpoints de leitura em 500.000 faixas
- [x] Disponibilização do índice de leitura de gêneros com testes de plano de execução
- [x] Mapeamento dos pontos de maior exigência computacional em consultas de agrupamento
Próximos desenvolvimentos
- [ ] Aprimoramento da paginação: Adoção de navegação por cursor nos endpoints sem parâmetro de offset
- [ ] Otimização consolidada das verificações de sessão em streaming contínuo