>> « un milliard de message jusqu'à maintenant » depuis quand ?
> Plurk a été lancé en mai 2008, d'après http://en.wikipedia.org/wiki/Plurk. Mais j'imagine que de manière similaire a de nombreux services qui rencontrent du succès, la croissance est très rapide, et quasiment tout le trafic a été fait sur les 6 derniers mois.
OK pour cette approximation, docn essayons un calcul simple : disons 1 millard de messages en 6 mois.
Donc 6 x 30 jours x 24 heures x 3600 secondes = beaucoup, que je divise par 1 milliard, puis 1/x = 64... 64 messages par seconde... bof... ;-) bon, OK, ça accélère, mais bon, voilà quoi...
>> Ça ne fait pas de présence ?
> Non, plurk ressemble plus à twitter qu'à de l'IM. Par contre, si tu as un lien qui explique pourquoi cette fonctionnalité est si demandeuse de ressources, ça m'intéresse.
Lien :
Un mec se connecte, il envoie sa présence, elle est diffusée à tous les items de son roster, qu'ils soient situés sur le même serveur, ou des serveurs distants fédérés (donc trafic local et inter-serveur).
Le mec change d'état manuellement quand il veut (pas souvent), sinon automatiquement, quand il s'éloigne de sa machine plus de n minutes, quand il rabat son écran et passe en veille, etc.
Et je ne parle pas des presence probes.
J'ai peu de stats sur la taille des rosters, mais estimons que Facebook est le pire des cas, et la taille moyenne de la liste de contacts là-bas est de 130 entrées.
Sachant qu'un user envoie et reçoit de la présence, quoi qu'il fasse, puisque le modèle est en push, mais qu'il ne fait pas forcément de messages, un serveur de présence et d'IM passe donc le plus clair de son temps (et de ses ressources) à router des présences.
[^] # Re: Les adminsys en redemandent
Posté par Nÿco (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 1.
> Plurk a été lancé en mai 2008, d'après http://en.wikipedia.org/wiki/Plurk. Mais j'imagine que de manière similaire a de nombreux services qui rencontrent du succès, la croissance est très rapide, et quasiment tout le trafic a été fait sur les 6 derniers mois.
OK pour cette approximation, docn essayons un calcul simple : disons 1 millard de messages en 6 mois.
Donc 6 x 30 jours x 24 heures x 3600 secondes = beaucoup, que je divise par 1 milliard, puis 1/x = 64... 64 messages par seconde... bof... ;-) bon, OK, ça accélère, mais bon, voilà quoi...
>> Ça ne fait pas de présence ?
> Non, plurk ressemble plus à twitter qu'à de l'IM. Par contre, si tu as un lien qui explique pourquoi cette fonctionnalité est si demandeuse de ressources, ça m'intéresse.
Lien :
Un mec se connecte, il envoie sa présence, elle est diffusée à tous les items de son roster, qu'ils soient situés sur le même serveur, ou des serveurs distants fédérés (donc trafic local et inter-serveur).
Le mec change d'état manuellement quand il veut (pas souvent), sinon automatiquement, quand il s'éloigne de sa machine plus de n minutes, quand il rabat son écran et passe en veille, etc.
Et je ne parle pas des presence probes.
J'ai peu de stats sur la taille des rosters, mais estimons que Facebook est le pire des cas, et la taille moyenne de la liste de contacts là-bas est de 130 entrées.
Sachant qu'un user envoie et reçoit de la présence, quoi qu'il fasse, puisque le modèle est en push, mais qu'il ne fait pas forcément de messages, un serveur de présence et d'IM passe donc le plus clair de son temps (et de ses ressources) à router des présences.