Mise à l'échelle pour le débit de requêtes (QPS)

La mise à l'échelle du débit signifie traiter plus de requêtes parallèles par seconde. C'est différent de la latence - le débit et la latence sont des directions de tuning opposées et ne peuvent pas être optimisés simultanément sur le même nœud.

Un débit élevé favorise moins de segments plus grands, de sorte que chaque requête touche moins de surcharge.

Tuning de performance pour des RPS plus élevées

• Utiliser moins de segments plus grands (default_segment_number: 2) Maximizing throughput
• Activer la quantization avec always_ram=true pour réduire les E/S disque Quantization
• Utiliser l'API de recherche batch pour amortir la surcharge Batch search

Minimiser l'impact des charges de travail de mise à jour

• Configurer le contrôle de débit de mise à jour (v1.17+) pour empêcher les recherches non optimisées de dégrader les lectures Low latency search
• Définir optimizer_cpu_budget pour limiter les CPUs d'indexation (par exemple 2 sur un nœud à 8 CPUs réserve 6 pour les requêtes)
• Configurer le fan-out en lecture retardée (v1.17+) pour la latence de queue Delayed fan-outs

Mise à l'échelle horizontale pour le débit

Si un seul nœud est saturé au CPU après avoir appliqué le tuning ci-dessus, mettez à l'échelle horizontalement avec des répliques de lecture.

• Les répliques de shards servent les requêtes à partir des shards répliqués, distribuant la charge de lecture entre les nœuds
• Chaque réplique ajoute une capacité de requête indépendante sans resharding
• Utiliser replication_factor: 2+ et router les lectures vers les répliques Distributed deployment

Voir aussi Horizontal Scaling pour les conseils généraux de mise à l'échelle horizontale.

Goulots d'étranglement des E/S disque

S'il n'est pas possible de garder tous les vecteurs en RAM, les E/S disque peuvent devenir le goulot d'étranglement du débit. Dans ce cas :

• Mettez à niveau vers des IOPS provisionné ou du NVMe local en premier. Voir l'impact de la performance disque sur la recherche vectorielle dans Disk performance article
• Utiliser io_uring sous Linux (kernel 5.11+) io_uring article
• En cas de vecteurs quantisés, préférer le rescoring global au rescoring par segment pour réduire les lectures disque. Exemple dans le tutorial
• Configurer un nombre plus élevé de threads de recherche pour paralléliser les lectures disque. La valeur par défaut est cpu_count - 1, ce qui est optimal pour la recherche basée sur RAM mais peut être trop faible pour la recherche basée sur disque. Voir configuration reference
• Si toujours saturé, mettez à l'échelle horizontalement (chaque nœud ajoute des IOPS indépendantes)

Ce qu'il ne faut PAS faire

• Ne pas s'attendre à optimiser simultanément le débit et la latence sur le même nœud
• Ne pas utiliser de nombreux petits segments pour les charges de travail de débit (augmente la surcharge par requête)
• Ne pas mettre à l'échelle horizontalement quand limité par les IOPS sans aussi mettre à niveau le tier disque
• Ne pas fonctionner à >90% de RAM (éviction du cache OS = dégradation sévère des performances)