Problème de performances sur la partie metrics

[FrancoisN2]

Bonjour,
je fais de l'insertion de metrics depuis une fonction openwhisk et globalement les temps d’exécution de requêtes d'insertion me paraissent très lentes : pour 4 séries dans la même requête, on dépasse la barre de la seconde entre le temps d'envoi des données vers ovh, le temps d'éxecution du script et le retour du code 200.

Est-ce normal. Vaut-il mieux 4 requêtes qu'une seule pour les 4 séries ? Dans le retour de la requête est-il possible d'avoir le temps d'éxecution chez vous ?

Exemple de code :
NEWGTS 'data1' RENAME { 'id' $id } RELABEL $ts NaN NaN NaN 0.1 ADDVALUE
NEWGTS 'data2' RENAME { 'id' $id } RELABEL $ts NaN NaN NaN 0.56 ADDVALUE
2 ->LIST
$token UPDATE

Merci d'avance pour toutes les informations que vous pourrez apporter sur le sujet.

[FrancoisN2]

y aurait-il un cold start chez vous ? Ou dernière option peut-être qu'au niveau de warpscript il existe une meilleure façon d'insérer les données. Auquel cas je suis preneur.

[miton18]

Bonjour @FrancoisN2 !

Effectivement plus d'une seconde pour 4 data points semble un peu élevé.
En testant votre exemple, le call s'effectue en 71ms.

Vous avez raison, une requête avec les 4 séries sera plus efficace que 4 requêtes de 1 métrique.
Pour mesurer cela vous pouvez vous baser sur le header X-Warp10-Elapsed qui contient la durée d'execution du script (39ms dans mon test).

Aucun cold start sur la platforme :-)

Il existe en effet une autre solution pour inserer des points, passer par l'API /update au lieu de /exec. La documentation de cette API est disponnible ici

[FrancoisN2]

bonjour et merci pour votre réponse !
De mon côté en testant depuis Quantum, effectivement, je ne dépasse pas les 50ms pour une seule requête d'insertion de 4 valeurs.
Je vais utiliser le header que vous mentionnez afin de voir où le problème se situe.

[FrancoisN2]

OK, grâce au header je peux constater que le temps d'insertion des données est correct. Merci déjà pour cette info. Reste le renvoi de la réponse. Est-ce Warp qui répond en direct ou y-a-t'il des couches qui pourraient ralentir le renvoi de la réponse ?

De mon côté je vais revérifier ce qui se passe.

[FrancoisN2]

Je viens de refaire quelques tests et d'analyser les logs sur les dernières 24heures.
Donc depuis une fonction IBM hébergée à Francfort, un appel pour insérer des metrics chez vous vous prend en moyenne 1.5secondes.
C'est le temps que met une requête de type fetch sur une fonction nodejs pour insérer la donnée chez vous et renvoyer la réponse. Le header Warp indique bien que le temps de requête est raisonnable (pas plus de 70ms).
Par contre un détail intéressant : ce problème n'est pas consistant. C'est à dire que certaines requêtes peuvent être résolues en 150ms (ce qui est déjà mieux).
Dernière info : je fais le même type d'appels vers d'autres serveurs mais je n'ai pas ce souci.

Auriez-vous une idée ? Merci d'avance.

[FrancoisN2]

Je viens d'effectuer d'autres tests :
pour une même requête j'obtiens un temps sur Warp à peu près similaire mais il me faut 3.6secondes pour récupérer la réponse d'un côté et 130ms de l'autre depuis la fonction openwhisk.

En faisant les mêmes requêtes depuis postman en France, j'obtiens des résultats tout à fait corrects (<=80ms)

Je vais donc aller voir du côté de chez IBM pour voir pourquoi la réponse met autant de temps à arriver. ..

[miton18]

Bonjour @FrancoisN2

Est-ce Warp qui répond en direct ou y-a-t'il des couches qui pourraient ralentir le renvoi de la réponse ?

Non, aucune couche n'induirai cette latence :-)

Donc depuis une fonction IBM hébergée à Francfort, un appel pour insérer des metrics chez vous vous prend en moyenne 1.5secondes.

La région sur laquelle votre projet Metrics est situé est à Gravelines, cela vient peut-être d'une latence réseau.

Je vais donc aller voir du côté de chez IBM pour voir pourquoi la réponse met autant de temps à arriver.

Nous serions très intéressé d'avoir, si possible, votre retour là dessus.

Cordialement,

[FrancoisN2]

Bon j'ai fait pas mal de tests. À priori le problème ne viendrait ni des fonctions ni de chez vous mais de l'a librairie que j'utilise pour utiliser l'API Fetch sur NodeJS10. Avec la librairie request-promise ça à l'air de passer sur mes tests unitaires. Du coup je vais essayer de passer le code qui fonctionne mal avec cette lib. Je vous tiens au courant.

[FrancoisN2]

Ok après pas mal de tests avec fetch et request-promise, eh bien tout fonctionne très bien de votre côté. Donc c'est super ! Globalement j'arrive à avoir des requêtes d'insertion avec des temps de l'ordre de 15ms. Donc c'est une très bonne nouvelle.

De mon côté je vais m'amuser à comprendre quelle promise me fout mes perfs par terre ;)

[miton18]

Bonjour @FrancoisN2 ,

tout fonctionne très bien de votre côté. Donc c'est super !

Content de vous savoir heureux :-)
N'hésitez pas si vous avez d'autres questions.

Cordialement,

[FrancoisN2]

Re.
afin de trouver la cause du souci, j'ai créé une nouvelle fonction qui ne fait qu'une chose : insérer des metrics. Elle est invoquée toutes les 15 minutes.

Et j'ai à nouveau le problème : des requêtes qui s'exécutent globalement vite (temps donné par le header x-warp10-elapsed) mais de temps en temps, un retour de la réponse très tardif, quelques secondes après.
(note: terme d’exécution cependant des fois ça coince un peu quand même, j'ai déjà atteint 270ms pour une requête qui prend 27ms d'habitude)

Donc d'où pourrait venir le délai entre l’exécution de la requête et le renvoi/réception de la réponse ?

Je remarque que dans la réponse je récupère un header x-app-txn. J'imagine que c'est un identifiant de transaction chez vous ? Auriez-vous plus de détails de votre côté ?

Merci d'avance !

[miton18]

Bonjour @FrancoisN2,

Oui, vous pouvez m'envoyer le x-app-txn en privé, je pourrai vous donner quelques infos supplémentaires.

[FrancoisN2]

Ok. Donc si je résume, le souci proviendrait

1. soit d'une latence réseau (mais à quel niveau ?)
2. soit d'une latence "autre" chez IBM ? (mais le "autre" reste vague)
3. une requête http non optimisée ? (y-a-t'il des headers spécifiques pour effectuer une requête metrics ?)

Sachant que le problème n'arrive que de temps en temps, voyez-vous d'autre scénarios ?
Merci encore pour vos retours.

[FrancoisN2]

Le problème a été pris en compte par le support de chez IBM. Si j'ai des infos intéressantes, je les communiquerai.

[miton18]

Bonjour @FrancoisN2

Peut-être qu'un test de latence réseau entre votre fonction et l'endpoint Metrics pourra vous apporter davantage d'informations. De nombreux packets NPM existent dans ce but, par exemple net-ping.

[FrancoisN2]

Oui effectivement, je vais tester cela parce que là je suis en train de faire des tests avec les ingénieurs de chez IBM et pour l'instant le seul résultat c'est que nous avons une latence réseau qui semble différer de temps à autres. En gros nous avons une fonction, par exemple, qui met régulièrement plus de 4 secondes pour récupérer les infos chez vous. Alors qu'une autre fonction met elle en moyenne 250ms.
Je vais essayer avec le paquet que vous proposez. Merci !

[FrancoisN2]

Ok après un paquet de tests et de suivi chez IBM, je confirme : il y un souci de latence réseau entre les serveurs basés en Allemagne et les serveurs chez vous avec des temps de réponse qui oscillent entre 450ms et 5 secondes alors que Warp renvoie des temps normaux (40-80ms).

Ces soucis de latence varient en fonction des jours. Des fois c'est rapide, des fois comme aujourd'hui c'est simplement désastreux.

Honnêtement, je ne sais pas vraiment ce qui se passe et si je peux y faire quoi que ce soit. Y-a-t'il un pb de bande passante ? Est-ce que vous avez des logs spécifiques pour la journée d'aujourdhui ? Merci d'avance.