ZEP-17 : Elaboration de l'API des membres

a marqué ce sujet comme résolu.

Là ça me paraît très théorique comme approche, ou alors encore une fois j'ai raté un truc.

Non, je confirme, la réalité colle à ta théorie (je suis encore dessus au boulot aujourd'hui).

En fait, tu n'as même pas garantie que tes 8 requêtes à t0 arrivent en même temps, puisque elles aussi sont soumises au réseau.

Le seul moyen d'avoir la garantie que les 7 workers sont utilisés en même temps, c'est de balancer des requêtes de plus en plus vite, et de monitorer le nombre de workers utilisés, et ce jusqu'à atteindre les 7 workers réellement utilisés.

Ah et au fait, on a trois cœurs en prod et en préprod. Et donc 7 workers gunicorn, qui conseille "2 x nombre de cœurs + 1".

+0 -0

@Javier : En fait si je résume en très gros, je vais essayer de simuler le plus près possible, 8 applications indépendantes qui utilisent l'API des membres pour vérifier toutes les 0.1 secondes si un nouveau membre c'est inscrit. C'est un use case susceptible d'arriver du moment qu'on a une API ouverte, d'autant plus que ce scénario ne nécessite pas de d'authentification.

Et donc si je reprend tes points :

tes requêtes sont synchrones : j'envoie, quand j'ai le résultat j'en envoie une seconde. Et ce, 500 fois d'affilée

Oui

tu utilises 8 threads en parallèle, donc 8 requêtes partent au même moment (à t0) et tu supposes que 8 workers seront utilisés côté serveur pour les traiter

Je ne supposes pas que 8 workers seront utilisés, j'espère juste que 7 workers sauront traiter 8 demandes qui arrivent quasi au même moment. ça devrait normalement bien se passer hein, mais c'est surtout pour tester ce cas, au cas ou.

dès la deuxième requête http, tes requêtes sont désynchronisées. Dès lors, difficile de savoir sur combien de workers tu tapes

Je crois que ce sont les workers qui t'ont embrouillé. En fait je m'en fou de savoir ce que les workers font, je me place uniquement coté utilisateurs et je vérifie mes résultats (header et content). A aucun moment je ne vais aller jeter un coup d'oeil sur le serveur, je vais juste m'assurer que celui-ci me renvoit les infos qu'ils doit me renvoyer dans des conditions un peu stressantes.

+0 -0

En fait ce qu'on essaie de t'expliquer, c'est que ton test n'a aucun sens :

  • Parce que ta volumétrie ne repose sur aucune donnée
  • Parce que ton nombre de threads ne correspond à rien : 8 utilisateurs virtuels qui font des requêtes toutes les 0.1 secondes, ça n'a absolument aucun sens
  • Parce que tu ne surveilles pas ce que fait le serveur et donc tu ne pourras rien déduire de ton test.

Mais encore une fois, si tu veux vraiment le faire, vas-y. Mais ne te plains pas que personne ne prendra en compte les résultats.

Personnellement je préfèrerais 100x que tu nous prépares un vrai test de charge de cette API.

En fait, les utilisateurs virtuels qui tapent toutes les 0.1 secondes, ça a un sens : quand tu essaies de trouver la charge maximale d'un serveur. Mais là ça nécessite de surveiller aussi le serveur.

+1 -0

Mmmh OK pour les workers, j'ai vraiment pas compris l'objet de ton test, je pensais que l'idée était de vérifier qu'il n'y avait pas un worker en l'air qui ne se tapait pas dans le cache, ou qu'une mise à jour n'invalidait pas le cache de la même façon pour tous les workers, ou un truc du style.

8 applications indépendantes qui utilisent l'API des membres pour vérifier toutes les 0.1 secondes si un nouveau membre c'est inscrit

Ça me paraît être un use case hautement improbable.

En gros si je traduis en termes fonctionnels : on a une application buggée (100ms faut être sensiblement stupide ou mal-intentionné pour faire du polling à cette fréquence là) installée sur 8 clients.

A la louche :

  • une appli Android
  • une appli iPhone
  • une appli web
  • deux notificateurs

On a 2000 membres, on va compter 50 utilisateurs par app connectés en même temps (et c'est énorme déjà).

50 * 50 = 250 clients.

250 clients avec des polling à 5s d'intervalle ça me paraît déjà moins fou comme test.

PS : j'ai pas lu le message de Spacefox potentiellement une redite donc.

+0 -0

100ms faut être sensiblement stupide ou mal-intentionné pour faire du polling à cette fréquence là

Javier

Du moment ou ton API est ouverte, tu ne peux pas t'assurer que tous les clients de ton API soient bien codées.

Tu visualise pas bien le cas.

Imaginons un notificateur pour chrome, chargé de nous avertir dès qu'un nouveau membre est inscrit sur le site. Derrière, le notificateur est codé de façon à ce qu'il envoit un GET à /api/membres/ toutes les x secondes (ce x étant paramétrable en dessous de 1 seconde) afin de notifier l'utilisateur dès qu'il remarque un changement.

Si cette application (le notificateur) est utilisé par 8 personnes physiques, on est exactement dans mon use case. Et donc, non seulement ça ne devrait pas faire souffrir le serveur, mais le cache à base de Etag devrait fonctionner normalement.

+0 -0

Gérer ce genre de conneries et envoyer chier les utilisateurs qui abusent, c'est pas très exactement le but du throttling qu'on essaie de mettre en place ?

PS : mon avis, c'est que le serveur n'a pas à servir le type qui s'amuse à taper sur l'API toutes les 0.1 secondes.

+1 -0

A 100% d'accord avec SpaceFox.

Ton test ne sert à rien… Tu crois que le mec qui code un client buggé (100ms) va s'amuser à t'envoyer un If-Modified-Since ? Tu peux lui envoyer le ETag que tu veux il n'en aura rien à fiche.

Alors peut-être que dans le cas d'un notificateur Chrome c'est Chrome qui se charge de positionner les headers de la requête HTTP, mais arrêtons deux secondes le délire. On est en train d'évaluer un use case dont on ne veut pas le client que t'as testé là, il est bon pour réaliser les tests de rate limitation quand elle sera en place (et c'est bien le but du jeu).

Qui plus est, si je ne m'abuse le but de délivrer des clés par application c'est bien de pouvoir les révoquer, non ? Parce que dans ce cas là je vais pas blinder mon serveur pour qu'il résiste à ça, par contre je vais vite fait bien fait invalider (au moins temporairement) la clé pour l'application.

Bref, franchement firm1 avec tout le respect que j'ai pour toi j'ai l'impression que t'es de mauvaise foi là et que t'essaies tant bien que mal de retomber sur tes pattes. Au départ le chiffre 8 était tout sauf un hasard, puis au final on s'en fiche, puis au final c'est logique parce que c'est 8 clients d'une même app buggée (mais les autres apps pas buggées n'entrent pas en ligne de compte dans le test ?).

Bref, c'est un peu un dialogue de sourd. Mais je suis de l'avis de SpaceFox, si tu considères que le test a un intérêt fais-le.

+2 -0

Qui plus est, si je ne m'abuse le but de délivrer des clés par application c'est bien de pouvoir les révoquer, non ? Parce que dans ce cas là je vais pas blinder mon serveur pour qu'il résiste à ça, par contre je vais vite fait bien fait invalider (au moins temporairement) la clé pour l'application.

Techniquement le test en question ne nécessite pas de clé justement et est donc a la portée de n'importe qui. Mais vous avez peut être raison, il vaut mieux attendre que le throttling soit en place pour réaliser ce genre de test.

+2 -0

il en est où le Throttling ? J'ai fais un test sur la preprod et je me prend un "too many request". Alors oui j'ai probablement dépassé les 60 en moins d'une heure mais là j'essaie de récupérer la liste des membres en étant connecté (normalement, j'ai bien mon access token et je l'envoie dans le headers) et j'ai toujours le blocage. Ça m'étonerai vraiment que j'ai dépassé les 2000 requetes en une heure…

+1 -0

Le throttling est en place et est fonctionnel. Cependant, pour une raison inconnue, les requêtes authentifiées sur un serveur protégé par un htaccess bloque les requêtes. SpaceFox et moi-même avons testé sans l'htaccess du serveur de bêta (juste le temps de tester avant de le remettre) et tout fonctionnait correctement.

Donc, nous avons 60 requêtes/heure pour les utilisateurs anonymes et 2000 requêtes/heure pour les utilisateurs connectés.

+0 -0

En fait je me demande un truc : si on veut envoyer une requete passant le htaccess, que fais curl/ton client pour envoyer identifiant, mot de passe et informer qu'il veut s'authentifier ?

Car je viens de me rendre compte que ma lib, (python) requests, changeait le champ "Authorization" de "Bearer" à "Basic" sans que je lui ai demandé.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte