Théorie pratique des files d'attente

Question

Je souhaite apprendre suffisamment de théorie de la mise en file d'attente simple/pratique pour modéliser le comportement d'une pile d'applications Web standard: Load balancer avec plusieurs backends de serveur d'applications. Étant donné un simple modèle de trafic extrait d'un outil comme NewRelic montrant le pourcentage de trafic vers une partie donnée d'une application et le temps de réponse moyen pour cette partie de l'application, je pense pouvoir modéliser différents comportements de files d'attente avec loadbalancer configuration, nombre de serveurs d'applications et modèles de files d'attente. Est-ce que quelqu'un peut m'aider à m'initier à la théorie de la mise en file d'attente/aux principes de base que j'aurais besoin de représenter mathématiquement ce système? Je suis gêné de dire que je savais comment faire cela comme un étudiant de premier cycle, mais j'ai depuis oublié tous les principes fondamentaux.

Mon objectif est de modéliser différents modèles d'équilibrage de charge et de mise en file d'attente de serveurs d'applications et de mesurer les résultats. Par exemple, il semble clair qu'une pile d'application N-mongrel Ruby on Rails aura un temps de latence/attente plus long avec une file d'attente sur chaque Mongrel qu'un système Unicorn/Passenger avec une seule file d'attente pour chaque groupe de travailleurs.

Answer 1

Je ne peux pas vous pointer à la théorie, mais il existe quelques méthodes de base dans l'usage populaire:

• aveugle (linéaire ou pondérée) rond-robining - demandes se succèdent par cycles n serveurs, peut-être en fonction d'une certaine pondération. Chaque backend maintient une file d'attente de requêtes. Une demande à exécution lente sauvegarde la file d'attente de demandes de ce travailleur. Un agent qui arrête de renvoyer des résultats est finalement supprimé du pool d'équilibrage, toutes les demandes en attente étant supprimées. Ceci est courant pour les configurations d'équilibrage haproxy/nginx. Pooling global - une file d'attente principale maintient une liste de demandes, et les travailleurs signalent quand ils sont libres d'accepter une nouvelle demande. Le maître remet l'avant de la file d'attente au travailleur disponible. Si un travailleur tombe en panne, seule la requête en cours de traitement est perdue. La performance est légèrement diminuée dans des conditions idéales (tous les travailleurs retournent rapidement leurs demandes), car la communication entre le maître de file et le backend est une condition préalable à la suppression d'un travail, mais évite naturellement les travailleurs lents, morts ou bloqués. Passenger utilise cet algorithme d'équilibrage par défaut, et haproxy uses utilise une variante avec son algorithme d'équilibrage "leastconn". Équilibrage haché - un composant de la requête est haché, et le hachage résultant détermine le backend à utiliser. memcached utilise ce type de stratégie pour les configurations fragmentées. L'inconvénient est que si la configuration de votre cluster change, tous les hachages précédents deviennent invalides, et peuvent correspondre à des backends différents qu'auparavant. Dans le cas de memcached en particulier, il en résulte une invalidation probable de la plupart ou de la totalité de vos données mises en cache (reddit subit some massive performance problems récemment en raison de ce type de problème).

D'une manière générale, pour les applications Web, je tendance à préférer la méthode de mise en commun globale, car elle maintient l'expérience utilisateur plus lisse lorsque vous avez des travailleurs lents ou morts.