On 09/11/2012 11:45, François wrote:
Pour vous opérateurs, ça change quelque chose le modèle push serveur
-> client (et donc le fait d'avoir des connexions persistantes)? Le
fait d'avoir des (dizaines de) milliers de clients qui se connectent
(donc suivant une répartition aléatoire sur une période temporelle)
vers une même destination, plutôt que d'avoir ce même (dizaine de)
millier de connexions ouvertes?
D'un point de vue réseau, ce qui compte c'est le nombre de paquets.
De ton point de vue, plus de sessions c'est aussi plus de charge sur les
serveurs et les firewalls (si statefull). Mais coté serveur ça va
dépendre des implémentations, puisqu'une ouverture de session peut
consommer plus que le maintient de plus de connexions ouvertes.
La question va plutôt être de savoir si tu as besoin de plus de paquets
pour le keepalive que pour le triple handshake (supposant que tu fais du
HTTP, donc du TCP) à chaque ré-ouverture de session.
J'aurais tendance à favoriser le keepalive et le pipelining dès que
l'applicatif le permet et dans l'espoir de maximiser la charge utile des
paquets.
Mais quitte à pousser la réflexion à ce stade, l'idéal est encore que
tout l'applicatif soit optimisé : sérialisation, minimisation et
compression de ce qui peut l'être, vrai gestion statefull des clients
connectés, gestion de reconnexion transparente en cas de perte de la
session malgré le kepalive...
Dans ce cas un des points d'optimisation peut être la spécialisation de
tes serveurs. Tu vas avoir différents rôles prédéfinis et différents
comportements pour chaque rôles, avec des heuristiques à implémnter dans
ton applicatif pour optimiser encore plus le comportement de ces rôles.
Le cas typique de mon point de vue c'est le jeu et ligne ou le site
social / de rencontre avec t'chat.
La première distinction que tu peux faire, c'est statique v;s.
dynamique. Sur le statique, ton objectif va être de profiter du
pipelining, et ce qui va compter c'est la capacité de ton sous-système
de stockage à accéder à tous les fichiers dans le délai du keepalive
(parfois les 5 secondes par défaut d'Apache ne suffisent pas, mais
quelle idée d'utiliser apache pour du statique ?).
Ensuite dans le dynamique, tu vas avoir la génération des pages et le
support de tes messages applicatifs. Sur la génération des pages, tu vas
généralement n'avoir qu'un fichier à envoyer par requête, et les
requêtes sont plutôt espacées, donc le keepalive ne sert à rien.
Par contre sur la classe de serveurs qui va supporter la messagerie
instantanée, tu as intérêt à l'augmenter au maximum dès qu'une
conversation est active. Ou plutôt que ton code coté client n'initie la
connexion que lorsqu'une conversation est effectivement démarrée.
Sur un site un peu gros, pour le coup tu vas plutôt avoir 4 à 6 familles
de serveurs frontaux :
- Les statiques invariables (images) : ce sont les I/O disque random
read qui chargent. Keepalive pour pipelining.
- Les statiques légèrement variables (js, css) : tu vas bouffer un peu
de CPU si tu ne pré-compresse pas, mais finalement tout le contenu se
retrouve en RAM, donc peu d'IO disque. Keepalive pour pipelining.
- Les dynamiques lourds (html) : ceux là tapent dans les bases pour
génerer uniquement l'ossature et agréger le contenu que tu auras
considéré comme statique. Pas de keepalive.
- Les dynamiques légers (html aussi, parfois json ou xml) : ceux là vont
générer des inclusions plus variables, genre le "top 5 instantané" ou la
liste des connectés. Per request uniquement, pas de keepalive.
- Les flux de contrôle par session (json ou autre) : ouverts pour tout
le monde, pour les notifications quelconques, pas forcement très
réactives donc un keepalive court et du polling toutes les 2-3 minutes
peut suffire
- Les flux applicatifs real-time (json ou autre) : là c'est spécialisé
pour la messagerie instantanée, les données de jeu en ligne, ...).
Keepalive long obligatoire.
Sur chaque famille tu vas avoir des profils de requêtes par utilisateur
assez différents pour avoir des optimisations adaptées à chaque
scénario, et donc faire un meilleur usage du keepalive pour gagner en
réactivité et minimiser la charge de tes serveurs.
Le fait de découper les serveurs par fonction de permettra aussi de
scaler et distribuer la charge (sous entendu en CDN et/ou sur plusieurs
hébergeurs) plus facilement.
@+
--
Jérôme Nicolle
06 19 31 27 14
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
