Volumétrie/Charge d'un serveur de lapins

Bonjour,

Avez-vous des informations sur la charge que subissait l'infrastructure violet ?

• Nombre de lapins au total (j'ai lu 150 000)
  
• Nombre de lapins simultanément connectés (j'ai lu 10 000)
  
• Nombre de requêtes XMPP / lapins / temps (heure, minute...)
  
• Nombre de requêtes HTTP (heures, chorégraphies, taichi, ...)
  

De mes souvenirs de bidouille, au lancement du lapin, il récupère son bootcode, fait quelques requêtes pour s'authentifier, récupérer des adresses de serveurs mais après ....

Il serait intéressant de décortiquer au maximum cette volumétrie, ça permettrait peut être d'optimiser le traffic.

Bonsoir,

Pour les nombres de requêtes, c'est assez simple on va dire:
> En HTTP, y'a deux/trois requêtes au boot du lapin, et ensuite, chaque Chorégraphie, chaque MP3 lu par un lapin compte pour une requête.

Si on compte 10 000 lapins connectés (boot complet), qui demandent l'heure (jsute ça hein), ca fait 10 000 requêtes concentrées en pic à chaque fois...

Les choré, à part le Taichi qui est fait en interne par le lapin, comptent chacune pour une requête...
Les MP3 pareil (sauf que y'a plus de données qu'une choré).

Mettons un ensemble choré/mp3 pour les humeurs du lapins. Disons qu'il fait ca deux fois par heure, 4 requêtes.

Etc, avec 10 000 lapins, on arrive très rapidement à un nombre phénoménal de requetes, on doit pouvoir approcher les 50 000 très facilement (sans les Flux RSS, les check d'email, webradios... )

Au niveau des requêtes XMPP, toutes les 10 secondes, un lapin ping le serveur XMPP, de plus, chaque requête HTTP est généralement accompagnée d'une (ou deux) requête(s) XMPP. Pour le boot d'un lapin, on a une vingtaine de trames d'échangées entre le lapin et le serveur.
Je vous laisse faire le calcul mais héberger 10 000 lapins simultanément, ca représente une charge énorme pour un particulier, je doute que quelqu'un puisse le faire, et je doute aussi que les serveurs Google Apps (dont vous avez parlé ailleurs) ne l'acceptent en gratuit...

M'est avis que la solution serveur privé va passer par une fragmentation de la communauté... Pas l'choix quoi.

RedoX a écrit:

Bonsoir,

M'est avis que la solution serveur privé va passer par une fragmentation de la communauté... Pas l'choix quoi.

CQFD. Merci pour cet avis que je trouve simplement ( et durement pour nos lapins) réaliste

Ca reste mon avis personnel hein, mais regardons les chiffres....

OpenJabNab (qui a ce jour est la solution la plus développée disponible) peut peut-être supporter un bon nombre de lapins (et encore, rien n'est prouvé) mais il n'a pas été pensé pour recevoir une telle charge.

A lire les avis des tech' de Mindscape, leur architecture est bancale (on s'en doutait, mais bon, ils tiennent une grosse charge eux quand même) donc même la libération des sources ne va pas trop servir pour maintenir la communauté vu son ampleur actuelle (sauf si quelqu'un de très fortuné mets en place un hébergement conséquent et du personnel pour s'en charger, mais ne rêvons pas trop). Certes les sources vont être utiles, pour le développement, mais guère plus je pense...

C'est pas un gus dans son garage qui va héberger 10 000 lapins. C'est triste pour la communauté, mais c'est l'éternel problème de toute centralisation, dès que le point central tombe... c'est la dèche.

Une solution (utopique ?) serait de décentraliser les serveurs Nabaztag, tout en les maintenant connectés entre eux. Mais là on en est très loin. Et développer un tel système demanderait du temps, que les développeurs bénévoles (rappelons le, tout le travail fait sur OJN l'est sur du temps libre) n'ont pas forcément.

Certes l'aspect communauté était important, mais je pense que les lapins peuvent rester attractifs en petits groupes. L'interaction Lapin/Lapin n'était pas le point central du Nabaztag. Certes c'est dommage, mais c'est ainsi.

Rien n'est perdu pour autant. On a encore le temps avant que nos lapins ne deviennent des presse papiers à part entière

Donc on aurait déjà comme grosse contrainte :

10000 lapins * 50ko (taille fichier mp3 heure ?) * 24h/jour * 30 jours par mois * ~ 350go/mois
-> 42$ pour du S3 chez Amazon (+ 7.2$ pour les requêtes)

mmm soit je me plante pour les tarifs S3, soit ça revient pas cher du traffic chez Amazon

Tu peux diviser par 2 ou 4 avec la perte en ligne des lapins qui vont finir au placard le 29

Même en divisant par deux, ca reste énorme, il ne faut pas juste compter le transit de données, mais surtout l'architecture pour gérer ces transferts...

On est entrain de se dire quoi ? Que cela est impossible alors. Techniquement toujours possible, financièrement ? Glup.

Je rebondi sur un truc ( surement bête ) des petits serveurs de 5 ou 10 lapins pour le trafic serveur / lapin et un site fédérateur qui coordonne l'ensemble ??

Heu si tu parles de 350 go par mois, c'est rien du tout à sortir de nos jours et heureusement.
Le problème devrait plus se situer sur les requêtes HTTP et XMPP et encore.

Si l'on compte 1000/2000 lapins connectés, ce sera déjà très très large. Et taper 1000/2000/3000 req/sec pour un serveur dimensionné, ça passe largement.

Sur les 150 000 Lapins et les 10/20K de connectés à Violet, combien traînent sur des forums qui en parle ?
Quand il va y avoir la coupure, ils y a très peu de chance qu'ils passent sur des "serveurs privés". Outre qu'il faut modifier des paramètres que tout le monde ne sait pas faire, ils passeront à la v3 ou ils jetteront le Lapin.

Loup Artic a écrit:

ou ils jetteront le Lapin.

J'espère plutôt qu'il vont les brader sur le net

Pour revenir au sujet, je pense que la solution est effectivement de fragmenter tout cela, et créer un système de peer to peer entre les serveurs, pour qu'ils puissent savoir où se trouve un lapin, et donc communiquer avec lui... Cependant, je pense que ça ne sera pas prêt avant un gros moment !

Je pense à un système où dans la configuration du serveur, on ajoute les adresses de serveurs qu'on connait, ces serveurs connaitront d'autres serveurs, etc...
Car 10000 lapins sur 1 serveur, ce semble impensable...
1000 lapins sur 1 serveur, ça semble plus raisonnable, mais il faut alors relier les 10 serveurs
100 lapins sur un serveur, ça doit passer, reste à relier les 100 serveurs..
Etc...

On pourrait aussi envisager 1 serveur qui serve d'annuaire, en disant : tel lapin, il est sur tel serveur...
Il suffirait d'inscrire son serveur sur l'annuaire, et tous les lapins seraient alors inscrits automatiquement.

C'est des idées en vrac, à 23h20, après une journée de 18h... Donc tout n'est pas forcement clair, surtout tapé sur un iPad ,qui a tendance à remplacer certains mots techniques par des trucs sans aucun rapport.

L'idée du serveur annuaire me semble la plus simple a mettre en place mais ATTENTION si celui-ci tombe les lapins ne pourrons plus communiquer entre eux ... Il faut donc penser a mettre un serveur "mirroir" au cas ou !

En somme des NabNS

Youri a écrit:

Donc on aurait déjà comme grosse contrainte :

10000 lapins * 50ko (taille fichier mp3 heure ?) * 24h/jour * 30 jours par mois * ~ 350go/mois

Bonjour,

Je viens regarder un peu les fichiers mp3, la taille varie de 6 à 12ko par mp3, donc pour l'heure on monterai à 3000 requêtes simultanée (en comptant les lapins oublié dans les placards) donc 3000 * 12ko = 36Mo. donc un pic à 36 Mo toutes les heures, ce qui est pas mal .. quand même, techniquement je pense que c'est gérable sur un ou deux serveurs, le problème est effectivement plus le prix de la bande passante, je peut trouver des serveurs, je peu même trouver de la place pour les mettre en baie dans un datacenter, je peu aussi trouver le temps de les administrer, et pour la bande passante je peu peut-être soudoyer mon chef (il a plusieurs lapins, lui aussi .

Par contre il faut absolument que le soft gère l'authentification par adresse mac des lapins, histoire de pouvoir verrouiller le nombre de lapins. Ceci permettra aussi de créer des communautés plus restreintes et ainsi de créer plusieurs (une ferme ) de serveurs de lapins.

Voilà pour moi

RedoX a écrit:

....Je vous laisse faire le calcul mais héberger 10 000 lapins simultanément, ca représente une charge énorme pour un particulier, je doute que quelqu'un puisse le faire, et je doute aussi que les serveurs Google Apps (dont vous avez parlé ailleurs) ne l'acceptent en gratuit...

M'est avis que la solution serveur privé va passer par une fragmentation de la communauté... Pas l'choix quoi.

Les serveurs gratuits ont tous leurs limites....mais si l'on doit financer un ou des serveur(s), c'est peut être la que l'on aura besoin de l'opération "sauver les Nabatag" voir ma signature.

Quand a fragmenter les lapins , il est évident que tout le monde ne tiendra pas sur un seul serveur...

Mais je ne pense pas que l'on soit obligé de fragmenter la communauté pour autant car si les nabzs sont répartis sur disons 2 serveurs (c'est juste un exemple) :
**exemple**
Le nabz (A) est enregistré sur le serveur sur 1 et le nabz (B) est enregistré sur le serveur 2.
Une interface graphique est accéssible par identification (utilisateur+mot de passe). Cette interface présente une suite de boutons ou menus déroulant ou que sais-je d'autre encore qui permette une selection...chaque selection délenchant l'écriture d'une partie d'une "phrase" qui une fois complete correspond a ce que l'on aurait pu taper si on avait codé en direct sous l'API (cette phrase serait invisible pour l'utilisateur bien sur...

Dans cette configuration, sur le bouton correspondant a "a quel lapin voulez vous envoyer le message blablabla" on cliquerait sur "lapin (A)", au niveau de l'écriture ca donnerait quelque chose comme ca : http://serveur1.com/vl/API?XXXXXX& (ou XXXXXX est le MAC du lapin) et si on veut envoyer une action sur le lapin (B), ca donnerait : http://serveur1.com/vl/API?XXXXXX&

Donc les adresses seraient stocké "en dur" dans un fichier, on n'a peut être pas besoin d'une base de données SQL, un simple .INI pourrait suffire pour ne pas surcharger les calculs (car si une interface pareille voit le jour, il faudra une grosse puissance de calcul sur le serveur qui la stockera vu le nombre de requêtes possiblement demandées j'imagine...

L'avantage de ce systéme est que il faudra s'indentifier sur le site (comme pour celui de violet) pour envoyer une action sur un lapin...donc ca évitera le spam.
Aussi, on pourra acceder a tous les lapins et dans tous les sens.



EDIT : @cbrassel tu as posté pendant que j'écrivais ce message, je suis content de voir que l'on se rejoint. Bienvenue sur le forum

Je suis pour une solution distribuée aussi, je pense même à séparer les serveurs en fonction du type de communication, un CDN pour héberger les mp3, les messages,..., un serveur qui s'occupe de la communication XMPP, un serveur qui s'occupe de l'interface web, ... Reste à voir si la synchronisation entre ces serveurs n'est pas trop couteuse.

nag a écrit:

Donc les adresses seraient stocké "en dur" dans un fichier, on n'a peut être pas besoin d'une base de données SQL, un simple .INI pourrait suffire pour ne pas surcharger les calculs (car si une interface pareille voit le jour, il faudra une grosse puissance de calcul sur le serveur qui la stockera vu le nombre de requêtes possiblement demandées j'imagine...

Je pense qu'une base ldap serait au poil pour ce genre de requêtes .. plus rapide qu'une base sql pour ce genre d'opérations et plus souple qu'un fichier .ini, elle permettrais en outre d'être splité sur plusieurs serveurs afin de répartir et la charge et surtout obtenir de la redondance en cas de soucis.

Humanbomb a écrit:

L'idée du serveur annuaire me semble la plus simple a mettre en place mais ATTENTION si celui-ci tombe les lapins ne pourrons plus communiquer entre eux ... Il faut donc penser a mettre un serveur "mirroir" au cas ou !

Si chaque petit serveur web avait dans un fichier avec la liste complète des autres lapins, il viendrai ce mettre a jour sur le site annuaire a intervalle régulier.
Avec ojn sur un petit hébergement type free ont peu être faire tourne 4 ou 5 lapin avec le liens avec l'annuaire ?

Bonjour.

Une base SQLite me paraît bien plus simple à administrer, switcher (d'un serveur à un autre), sauvegarder, ...
Niveau rapidité, la base peut être chargée en mémoire et ainsi les accès sont bien plus rapides.

OJN ne tournera pas chez free qui n'héberge que du PHP

Désolé je voulais dire libre, gratuit pas forcement ce FAI

Pourquoi ojn n'est pas en php ?

Ojn est composé d'un frontend Php, ET d'un serveur en C++ qui fait la majorité du taff.

Edit: En relisant mon post, j'me rend compte que j'avais répondu rapidement: Pourquoi ? Parce qu'il faut avoir un serveur XMPP. Autant, avant le passage à XMPP des lapins, on pouvait tout avoir en PHP (regardez OpenNab et les autres par exemple). Autant, maint'nant, il faut en fait deux serveurs: Un serveur HTTP, et un serveur XMPP, ce qui n'est pas... idéal, on va dire, en Php/

On peut toujours changer le bootcode du lapin pour le "dé-jabberiser". Mais je ne suis pas convaincu que l'architecture HTTP-only soit la meilleure pour gérer des centaines de lapins sur un même serveur.

EDIT : OMG ! 1337 messages !
C'est bon je sors, pas besoin de taper.

On pourrait, mais ca serait un gros retour en arrière... Bien dommage quoi ^^

L'architecture Http/XMPP reste envisageable, mais il faut laisser le temps aux dev' de sortir un projet présentable en beta test pour une communauté. Jusqu'alors le développement d'OJN se faisait mono-utilisateur... Mais on y travaille ^^

L'architecture uniquement http n'est pas idéale, principalement car elle est beaucoup moins réactive que celle utilisant le protocole Jabber (xmpp).

En effet, le protocole Jabber permet au serveur d'envoyer des consignes au lapin... Par exemple, c'est le serveur qui va dire au lapin toutes les heures qu'il faut jouer le mp3 pour l'horloge parlante. Donc dès qu'il y a quelque chose à faire, le lapin va le faire.

Avec le protocole uniquement http, c'est le lapin qui va interroger régulièrement le serveur pour lui demander s'il a une action à effectuer. Par défaut, c'est une interrogation toutes les 10 secondes (avec opennab, on pouvait réduire ce délai).
Donc prenons une exemple. Il est 13h59 et 59 sec, le lapin interroge le serveur, qui lui demande s'il doit faire une action, le serveur répond qu'il n'y a rien à faire... La prochaine interrogation sera à 14h00 et 9 sec... Donc le temps d'avoir la réponse du serveur, et de télécharger le mp3.... Le lapin dira qu'il est 14h avec 10 sec de retard. Pour peu que le serveur ne soit pas à l'heure, le lapin raconte n'importe quoi

Et si on veut réduire le délai (il me semble qu'on descendait autour de 3 secondes avec opennab), on augmente rapidement le nombre de requêtes versle serveur.. Par défaut, on a 6 requêtes par lapin par minute. Avec un délai de 3sec, on passe à 20 requêtes par lapin parminute, et si on veut la réactivité de Jabber, on doitnavoir un délai de 1 sec, soit 60 requêtes par minute par lapin. Ca peut sembler peu, mais en imaginant 10 lapins sur un serveur, réglé avec un délai de 1 seconde.. On attaque le serveur avec 10 requêtes par seconde... Et là, si on commence à rajouter les mp3, etc... Ça va vite saturer le serveur !

Donc si je suis bien,
opennab ne pourrait "écouter" les ordres de qq lapins puisque c'est le serveur qui exécute l'ordre qu'on lui donne. Donc forcement une infrastructure de type décentralisé avec éventuellement un annuaire central( voir autres posts ).
Openjabnab marche dans l'autre sens, il donne l'ordre aux lapins, donc dans une infrastructure centralisée il va donner autant d'ordre "il est 23h00" que de lapins connectés ! Cela dans la même seconde !

Toujours pareil, ils faut centralisé ?
- on pilote depuis un point central
- on gère la Securite et les sauvegardes plus facilement
- une seule base d'information
- je coupe le courant est plus rien ne marche
Décentralisé :
- je sécurise le fonctionnement
- du mal a sauvegarder
- j'ai du mal a suivre qui fait quoi

Dans mon job je suis passé de la centralisation totale a une décentralisation douce en 3 ans