Salut,
pour faire du loadbalancing entre plusieurs instances d'une application dans un javascript, je cherche une méthode pour répartir les usagers de manière déterministe.
 
Actuellement la répartition se fait par exemple comme ça :

 
Avantage: il est facile de suivre et d'analyser toutes les requêtes d'un même type pour un utilisateur donnée puisqu'elles sont toutes résolues par le même serveur/
Inconvénient: ça répartit un peu la charge, mais pas équitablement, certains types de requêtes étant plus fréquents que d'autres.
 
Pour une meilleure répartition, j'ai essayé de faire quelque chose avec du Math.random pour chaque requête. Ca améliore la distribution, mais il devient quasi impossible de suivre les connexions d'un usagers parce qu'elles sont justement réparties ça et là.
 
Donc en gros, je cherches une méthode pour obtenir un identifiant propre au poste/utilisateur/client que je pourrais utiliser pour répartir les connexions. Genre obtnir un nom de machine, une IP locale, etc. Il faut que ça soit compatible tout navigateur, et que cet identifiant soit unique au moins le temps de la session de l'utilisateur. Des idées ?
 
Merci.

Math.random + cookie ?
 
une concaténation de propriétés relatives au navigateur ? (bon, en intranet ca sera pas terrible). T'es réellement limité au js ? parce que si tu peux recuperer l'ip du client, coté serveur, quitte a le mettre dans une variable js générée, tu peux t'en sortir, mais avec que du code coté client...

je peux pas avoir de cookie, ni rien, et il faut que ça se fasse par le client. La seule chose que je peux faire, c'est évaluer quelque chose. à chaque requete, j'ai une fonction javascript d'appelée, et je peux juste travailler avec elle sans effet de bord.
 
le problème de l'identifiant du poste, c'est que le parc informatique est homogène, et donc ça va souvent généré la même chose.

tu peux tout a fait ecrire/lire un cookie en js voir http://developer.mozilla.org/en/do [...] ent.cookie par exemple.
Pour l'ip par contre c'est pas possible en js ( à ma connaissance) mais tu peux eventuellement faire appel à un script js qui est en fait un script serveur, qui te sette une variable ip.
edit: si tu aimes pas l'import, tu peux egalement envisager un xmlHttpRequest dans ta fonction js vers un script serveur qui te retournerait uniquement l'ip de ton visiteur.

Ouais, si tu peux quand-même accepter un cookie en client-side... Sinon en général, les solutions pour avoir un identifiant utilisent une combinaison entre ip + navigateur + langue sélectionnée. Maintenant évidemment sur un parc homogène, va pas y avoir beaucoup de différences...

mais est-ce qu'il y a une méthode simple pour récupérer côté client son IP (et pas 127.0.0.1) et sans dialogue avec le serveur ? Je n'ai trouvé aucune documentation là dessus.

A cause des problèmes de sécurité pouvant survenir, y'a rien en JS pour trouver l'IP, à part générer un script sur le serveur

bon bah je suis donc coincé avec Math.random

mais t'as vraiment pas moyen de faire un coup xmlHttpRequest dasn ton js

Pour info, j'ai trouvé une solution très performante. La répartition est quasi-idéale, les gains sont impressionnants. J'ai essayé différentes méthodes de hash, mais finalement, j'ai fait très simple :

 
Ca fonctionne bien, la répartition est déterministe et en rejouant des données j'ai validé statistiquement que la distribution était adéquate.

Genre tu prends la longueur de la requête ?

pourquoi pas, apres tout ?

Ce qui m'intrigue dans cette histoire, c'est pourquoi laisser faire au client vu que c'est impossible de faire une répartition totalement égale
 
Alors qu'en plus côté serveur, tu peux évaluer la charge et répartir le client à chaque requête en fonction de la charge à ce moment Je suis consciens que ça a un coup, peut être la réponse à ma question

la longueur de la requête, c'est une fonction de hash simple mais qui fonctionne bien dans mon cas. Et c'est au client de parler avec le bon serveur, parce que je n'ai pas de frontal donc les serveurs ne peuvent pas se répartir entre eux la charge. Il n'existe pas de frontal pour ce que je fais. Le prix n'est pas un problème. La plateforme en place est bien dimensionnée, il s'agit surtout de mieux utiliser les matériels existant, pour ne pas avoir de serveurs qui se tournent les pouces.  
 
Avec la longueur de la requête, ça marche plutôt bien, la distribution est homogène. J'en saurais plus avec les stats que j'aurais lundi, mais a priori, c'est quasi-parfait.
 
Biensur j'aurais préféré router toutes les requetes d'un poste vers un même serveur pour faciliter la tracabilité et profiter de pipelining.