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 les segments moins nombreux mais plus volumineux afin que chaque requête génère moins de surcharge.

Tuning des performances pour un RPS plus élevé

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

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

• Configurer le contrôle du débit de mise à jour (v1.17+) pour éviter que les recherches non optimisées dégradent les lectures Low latency search
• Définir optimizer_cpu_budget pour limiter les CPU d'indexation (par exemple 2 sur un nœud à 8 CPU réserve 6 pour les requêtes)
• Configurer le fan-out de lecture différé (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é en CPU après application du tuning ci-dessus, passez à l'échelle horizontale avec des répliques de lecture.

• Les répliques de shards servent les requêtes à partir de shards répliqués, distribuant la charge de lecture sur 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 conserver tous les vecteurs en RAM, les E/S disque peuvent devenir le goulot d'étranglement du débit. Dans ce cas :

• Passer d'abord à des IOPS provisionnées ou du NVMe local. Voir l'impact des performances disque sur la recherche vectorielle dans l'article Disk performance
• Utiliser io_uring sur Linux (kernel 5.11+) article io_uring
• En cas de vecteurs quantifiés, préférer le rescoring global au rescoring par segment pour réduire les lectures disque. Exemple dans le tutoriel
• 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 bas pour la recherche basée sur disque. Voir la référence de configuration
• Si toujours saturé, procédez à une mise à l'échelle horizontale (chaque nœud ajoute des IOPS indépendantes)

Ce qu'il ne faut PAS faire

• Ne pas s'attendre à optimiser le débit et la latence simultanément 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 passer à l'échelle horizontale quand les ressources sont limitées par les IOPS sans aussi améliorer le niveau disque
• Ne pas fonctionner avec >90% de RAM (éviction du cache OS = dégradation grave des performances)