Relecture C10k[modifier | modifier le code]

Résumé de l'article[modifier | modifier le code]

Le C10k Problem, ou problème des 10000 connexions simultanées, est l'expression utilisée pour décrire la limite du nombre de connexions possibles sur un serveur. Cette limite est apparue lors de l'essort mondial de l'internet : Des millions d'internautes provoquant des dizaines de millions de requêtes systèmes sur les serveurs interrogés. La limite C10k a plusieurs causes identifiées : les systèmes d'exploitation des serveurs (OS Serveurs) et leurs manières de traiter les appels de ressources (threads et processus) et les entrées/sorties (I/O), les applicatifs serveurs dans leur traitement des requêtes et l'augmentation des débits qui facilitent et donc multiplient les accès sur les serveurs.

Explication des blocages provenants des systèmes d'exploitation

Appels de ressources et gestions I/O :

Modèles de communications concurentes, thread-driven, event-driven ou hybrides.
Gestion des I/O, bloquants ou non, synchrones ou asynchrones

Historique

Il est affirmé que le problème réside dans la mise en oeuvre des systèmes d'exploitation et cite les différentes évolution de ces systèmes dans leurs gestions des I/O et appels ressources entre 1983 et 2006

Avant de lister des solutions exitantes un point est fait sur les limites des mécanismes standards des descripteurs de fichiers.

Solutions existantes

Des solutions ont été proposées pour contrer les différentes causes, majoritairement sur les problématiques système d'exploitation dans leurs gestion des I/O et des appels ressources essentiellement suite aux travaux de D. KEGEL en 2006

Différents supports de dévelopement sont proposés dans les solutions : Erlang (avec les serveurs Mochiweb et Yaws), SEDA et Node.js.
Différents serveurs sont aussi proposés, nginx, lighttpd, Cherokee, Tornado et G-WAN.

Architectures de serveurs

Enfin est exposée l'architecture classique client-serveur et sa contribution au C10k suivie d'une autre approche, scalablité, qui permet de limpiter les risques de C10k.

Analyse de l'Article[modifier | modifier le code]

Préambule[modifier | modifier le code]

Il n'y a dans cette analyse aucune volonté de "planter" les auteurs de l'article. Il faut y voir des propositions de clarifications ou référencements, voire de réaménagement de l'article.

Il est toujours plus facile d'analyser le travail des autres que le sien, ce que j'ai pu apporter en contribution WiKi n'est pas forcément de qualité supérieure. Je laisse le soin à d'autres membres de la communauté de me le remonter.

Structure[modifier | modifier le code]

Plusieurs analyses du problème et plusieurs solutions sont indiquées. Il y a une explication claire d'une requête http, sans pour autant remplacer un article sur HTTP.

Par contre, il est essentiellement question d'OS UNIX/Linux et quasiment pas de Windows.

Il n'est question que de protocole http, est-il le seul impacté par C10k, ou y-a-t-il d'autres protocoles impactés ?

La limite C10k, son concept, ont-il été remis en question dans la communauté informatique ?

Le texte va très vite dans le particulier ou dans le détail, il n'y a quasiment pas d'explication générale.

Le plan n'a pas une bonne organisation : l'historique est au milieu de l'article, "les limites des mécanismes standards" est une partie qui devrait se trouver comme sous chapitre de la problématique. Dans l'historique, il est fait mention des modèles 1:1 et M:N qui ne sont abordés que dans la partie "Implémentation des threads dans les OS"

Le paragraphe "architecture classique client-serveur" devrait se trouver dans la Problématique, quant à la "scalabilité" elle devrait se trouver dans les solutions envisagées.

Forme[modifier | modifier le code]

Le style est peu encyclopédique, certaines phrases ont une forme lourde, certaines notions restent floues.

"Une optimisation a été apportée en mettant en œuvre un pool de threads qui distribue les tâches d'exécution sur des threads créés, initialisés par avance. Ainsi, le gain ce situe au niveau du temps inhérent à la création et à la suppression des threads[10][11]. Ce modèle est proposé dans les langages de programmation tel que Java[12]." pool : Il est question de billard ? "Le modèle event-driven est adapté pour les applications hautement concurrentes [15]. Les raisons sont que les systèmes event-driven permettent des optimisations qu'il est difficile de mettre en place dans les modèles threads-driven, des messages peuvent être traités en traitement par lots[15], un meilleur ordonnancement est possible, le contrôle de flux est plus flexible, et il n'y a pas de basculement de contexte[15]."

Même si le détail de la notion se trouve dans l'article cité en référence, la phrase reste floue. Aller dans la ref ne devrait servir que si on veut approfondir la notion.

"Le modèle par événements ne prend pas en charge le Multiprocessing (en), ne tirant ainsi pas avantage des architectures multiprocesseurs[18]. D'autre part, la gestion par événements est dépendante de mécanismes pas forcément correctement supportés par le système d'exploitation ou le langage. Enfin les programmes sont souvent plus complexes à développer et à debugger[19]."

Style non encyclopédique "pas forcément" est du domaine de la supposition, du conditionnel. Il faut être affirmatif, et sourcer cette affirmation.

"Pour essayer de tirer partie des deux modèles, un modèle hybride a été conçu. SEDA[note 5] est un framework s'appuyant sur les trois composants qui font la force des modèles Event Driven et Thread Driven que sont les tâches, queues et pool de threads. Ce framework utilise également une queue d’événements, un pool de threads et un gestionnaire d’événements[20] (cf « SEDA (Staged event-driven architecture) »)." queue et pool, toujours du billard ? Je me fais l'avocat du diable, mais tout le monde n'est pas féru de fonctionnement d'un système d'exploitation.

"Un processus utilisateur qui effectue un appel système select() indique en paramètre (via des bit-maps) son intérêt dans 3 types d'événements/état d'un descripteur : readable (i.e. qui peut être lu) sans blocage, writable (i.e. qui peut être écrit) avec blocage, exception/erreur. Le noyau va alors envoyer en retour l'ensemble des descripteurs ready(traduction, ou iltalique si la notion a été abordée) pour le type de descripteur demandé[29]."

bit-maps : notion non expliquée.

Certaines références (ex.: 22, 23, 24, 27 et 28) ne respectent pas le format "Harvard", il manque le numéro de page. D'autres donnent des liens vers des discussions (41) ou des sites officiels comme Cherokee, il aurait fallu donner les liens dans une liste de sites après la bibliographie et non les inclure directement dans la liste des références.

Fond[modifier | modifier le code]

L'article est, à priori, à jour. Dans la mesure ou je découvre le C10k à travers ces infos, et après regard sur les références, les données récentes ont été consultées. Je n'y ai pas vu d'éléments "Hors-Sujet" bien que la part belle soit faite aux systèmes d'exploitation.

"plusieurs serveurs web ont vu le jour, permettant de dépasser les 10k connexions simultanées. Parmi eux Nginx (2002), Lighttpd (2003) et Yaws (2002)." Ref Nécessaire

"mécanismes sans mémoire Entre deux appels, ils ne mémorisent pas les descripteurs qui intéressent les applications – cela est dû au fait que les deux tâches, correspondant à l'attachement à un événement et à la recherche d'un événement, sont imbriquées dans le même appel système." Ref Nécessaire

"manque d'optimisation pas plus de 512 descripteurs ouverts en même temps." Ref Nécessaire

Il y a un manque de neutralité dans certaines affirmations :

"Historique Le problème réside donc dans la mise en oeuvre des systèmes d'exploitation[2]." Celà occulte les autres éléments présentés dans la problématique. Comme si tou le C10k n'était qu'un simple problème de système d'exploitation.

"Yaws (en) est un serveur http très performant adapté particulièrement au contenu dynamique des applications Web." Cette affirmation se base sur quels critères ? Les éditeurs de Yaws en sont-ils la source ? Ou est-ce un simple avis personnel ?

"Node.js Node.js est un framework Javascript server utilisé au-dessus de Google V8, le très performant moteur Javascript open source implémenté dans le navigateur Google Chrome." Même réflexion, est-ce une opinion personnelle de la qualité de Node.js ?

Pour les deux affirmations précédentes, il aurait été bon d'avoir des éléments de comparaisons : nombres mesurés de connexions simultannées, mesures de temps de réponses des serveurs mis en concurence les uns et les autres. D'autant plus que ce genre de données, étayants une affirmation, sont présentes pour la comparaison entre les serveurs Nginx, Lighttpd, Cherokee et Apache (il aurait été bon de préciser l'unité de temps dans le graphique).

Certaines références (dont 75 et 84) portent sur des blogs. Est-ce que ces sources sont fiables d'un point de vue encyclopédique ?