Load balancing at a connection level

Ouverte
#110 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
À clarifier
Activité
À l'abandon
Stack technique
kubernetes, python

Piste de recherche

Commencez par le point d’entrée Python riva.client.ASRService(auth) et les définitions Kubernetes Deployment et Service incluses dans le rapport. Déterminez si le client réutilise les connexions et si cela explique le déséquilibre observé entre les pods ; le travail est terminé lorsqu’une cause confirmée ou les éléments manquants nécessaires pour le reproduire sont documentés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

I have an application with two pods and some client from inside the same cluster connecting to them by a service, as far as I know this will do a connection level multiplexing.

There is no reason for the workload to be consistently higher at one pod than another, yet I can see one of the pods receiving nearly 3 times more load than the other over a period of 3 hours.

image

The pod with more load was already running when the other pod started.

My first hypothesis was session stickiness, but a quick test shows that the connections are balanced

for _ in `seq 300` ; 
do
   curl -b cookies.txt -c cookies.txt -s riva-api.riva:8002/metrics | grep '^nv_gpu_utilization'; 
   sleep 0.1; 
done | awk '{print $1}' | sort | uniq -c

My new hypothesis is that python riva client is reusing the connections. Does that make sense or we are guaranteed to start a new connection when calling riva.client.ASRService(auth)?

Here you can find some snippets of the configuration

riva-api (pod) partial definition

apiVersion: apps/v1
kind: Deployment
metadata:
  name: riva-api
  namespace: riva
  labels:
    app: riva-api
    release: riva-api
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: riva-api
      release: riva-api
  template:
    metadata:
      labels:
        app: riva-api
        release: riva-api
    ...
    spec:
      ...
      containers:
        - name: riva-api
          image: nvcr.io/nvidia/riva/riva-speech:2.14.0
          ...

riva-api-online definition

apiVersion: v1
kind: Service
metadata:
  name: riva-api
  namespace: riva
spec:
  ports:
      ...
  selector:
    app: riva-api
    release: riva-api
Langage dominant
Python
Étoiles
143
Forks
52
Métriques de merge des PR
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de nvidia-riva/python-clients

Toutes les issues de nvidia-riva/python-clients

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.