IP Girl
  1. IP Girl
  3. Avantages et inconvénients de la stratégie Sticking Session / Session Affinity
Intereting Posts
Comment Photoshop combine-t-il deux images ensemble? Java arrondis tous les numéros Comment supprimer “href” avec Jquery? Java: Class.this JAXB crée le contexte et les marshallers coûte Pourquoi la gestion explicite des threads est-elle une mauvaise chose? Quel micro ORM utiliser? Flouter une image via CSS? Journalisation des messages de demande / réponse lors de l’utilisation de HttpClient Comment les cookies HttpOnly fonctionnent-ils avec les requêtes AJAX? Ruby – test pour le tableau Taille de la masortingce OpenCV Comment obtenir une réponse ASP.NET MVC Ajax pour redirect vers une nouvelle page au lieu d’insérer la vue dans UpdateTargetId? Que signifie l’esperluète unique après la liste de parameters d’une déclaration de fonction membre? Comment trouver l’ancêtre commun le plus bas de deux nœuds dans un arbre binary?

Avantages et inconvénients de la stratégie Sticking Session / Session Affinity

Une approche de la haute évolutivité consiste à utiliser l’équilibrage de la charge réseau pour répartir la charge de traitement entre plusieurs serveurs.

Un des défis que présente cette approche est que les serveurs sont sensibles à l’état – stockant l’état de l’utilisateur dans une “session“.

Une solution à ce problème est la “session collante” (également appelée “affinité de session”) dans laquelle chaque utilisateur est affecté à un seul serveur et ses données d’état sont contenues sur ce serveur exclusivement pendant toute la durée de la session.

Quels sont les avantages et les inconvénients de l’approche “sticky session”? L’utilisez-vous et si oui en êtes-vous satisfait?

Avantages:

  • c’est facile – aucune modification d’application requirejse.
  • utilise mieux les caches de RAM locaux (par exemple, recherchez une fois le profil de l’utilisateur, mettez-le en cache et pouvez le réutiliser lors de visites ultérieures du même utilisateur)

Les inconvénients:

  • Si le serveur tombe en panne, la session est perdue. (Notez qu’il s’agit d’un con de stocker les informations de session localement sur le serveur Web – pas de sessions en soi en soi). Si ce qui est dans la session est vraiment important pour l’utilisateur (par exemple un brouillon de courrier électronique) ou pour le site (par exemple un panier d’achat), perdre l’un de vos serveurs peut être très pénible.
  • En fonction de l’implémentation “collante” de votre équilibreur de charge, il se peut que la charge inégale sur certains serveurs soit dirigée contre d’autres
  • Si vous installez un nouveau serveur en ligne, la charge du nouveau serveur n’est pas immédiate – si vous disposez d’un système dynamic d’équilibrage de la charge pour gérer les pics, le blocage risque de ralentir votre capacité à réagir rapidement. Cela dit, il s’agit là d’un cas particulier et ne s’applique vraiment qu’à des sites très vastes et sophistiqués.
  • Si vous avez relativement peu d’utilisateurs mais que le trafic d’un seul utilisateur peut saturer un serveur (pages complexes avec SSL, AJAX, images générées dynamicment, compression dynamic, etc.), les stickines peuvent nuire au temps de réponse de l’utilisateur final. répartir uniformément la charge d’un seul utilisateur sur les serveurs. Si vous avez beaucoup d’utilisateurs simultanés, ceci n’est pas un problème puisque tous vos serveurs seront submergés!

Mais si vous devez utiliser l’état de session serveur-local, les sessions sticky sont certainement la voie à suivre – et même si vous n’utilisez pas l’état de session serveur-local, la durée d’adhésion présente des avantages pour l’utilisation du cache (voir ci-dessus). Votre équilibreur de charge doit être en mesure d’examiner les cookies HTTP (pas uniquement l’adresse IP) pour déterminer l’adhésion, car les adresses IP peuvent changer au cours d’une même session (par exemple, connecter un ordinateur portable à un réseau câblé ou sans fil).

Mieux encore, n’utilisez pas l’état de session sur le serveur Web! Si l’état de la session est très pénible à perdre (par exemple, les paniers d’achat), stockez-le dans une firebase database centrale et nettoyez régulièrement les anciennes sessions. Si l’état de la session n’est pas critique (par exemple, nom d’utilisateur / URL avatar), insérez-le dans un cookie. Assurez-vous simplement de ne pas trop charger de données dans le cookie.

Les versions modernes de Rails, par défaut, stockent les variables de session dans un cookie pour les raisons ci-dessus. D’autres frameworks Web peuvent avoir une option “store in cookie” et / ou “store in DB”.