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.
Problème de performances sur la partie metrics
Sujets apparentés
- [ Metrics ] New release : 2.0
5690
26.06.2017 22:06
- [Metrics] Grafana completely broken (fixed)
3942
02.01.2017 10:44
- Evaluer le volume envoyé de logs
3804
28.10.2016 00:07
- Envoi des logs depuis un cluster kubernetes via fluentd
3493
31.10.2016 13:28
- Supprimer data/Metrics sur opentsdb
3106
05.03.2018 15:48
- [Metrics] Data source InfluxDB dans Grafana
2847
12.01.2018 10:45
- [FR] [Metrics] Support du protocole Graphite disponible !
2766
28.12.2017 14:08
- Coupures de service ?
2619
29.05.2019 16:10
- [Metrics] How query your data using graphite ?
2261
29.12.2017 17:32
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.
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
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.
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.
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.
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. ..
Bonjour @FrancoisN2
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,
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.
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 ;)
Bonjour @FrancoisN2 ,
Content de vous savoir heureux :-)
N'hésitez pas si vous avez d'autres questions.
Cordialement,
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 !
Bonjour @FrancoisN2,
Oui, vous pouvez m'envoyer le `x-app-txn` en privé, je pourrai vous donner quelques infos supplémentaires.
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.
Le problème a été pris en compte par le support de chez IBM. Si j'ai des infos intéressantes, je les communiquerai.
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 https://www.npmjs.com/package/net-ping net-ping.
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 !
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.