Utilisateur:Rbouquet

Régis Bouquet

   * né en 1968
   * Résidant à : Lyon, France
   * Employé par France Telecom chargé d'O&M et Etudes Sondes
   * Parcours de professionnalisation Master spécialisé Tiir 2010-2011 Université Lille

Résumé introductif suite à la lecture de l'article C10k problem[modifier | modifier le code]

Le présent article présente le cas du C10K problem. Ce problème est relatif à une limite de fonctionnement nominal rencontrée par les serveurs informatiques à partir d'un seuil de 10000 connexions simultanées. Tout d'abord la partie 1 Problématique rappelle le contexte de très forte montée en charge des réseaux et plateformes de services survenue au cours des 20 dernières années. C'est donc dans ce contexte que le c10K problem est analysé. L'énoncé du principe général pour la gestion des communications concurrentes explique comment sont traitées les requêtes émises par des machines clientes vers des serveurs. Cela permet d'introduire l'intérêt du vieux mais toujours actuel débat d'experts qui sévit à propos des 2 principaux modèles utilisés au niveau des systèmes d'exploitation informatiques: le thread-driven ou event driven, tous deux pouvant également être mixés dans un troisième modèle alors dit hybride. Avantages et inconvénients de chacun sont rapportés. On termine finalement la partie problématique par l'énumération et la définition des différentes gestions des mécanismes d'entrées-sorties adaptables en fonction des catégories de serveurs déployés. Le c10K problem est ensuite mis en perspective dans une partie 2 Historique qui rappelle les dates clés de son évolution depuis sa première mise en exergue dès 1983 jusqu'à tout récemment en 2010. Sont ici répertoriées par date les publications majeures d'études de modèles ainsi que les les principales livraisons de mécanismes et bibliothèques utiles à sa gestion. En 3 Limites des mécanismes, la gestion des messages entre les fonctions applicatives et le noyau est revue avec une mise en exergue des contraintes rencontrées. A ce stade, la section 4 Solutions existantes identifie les deux principales familles de réponses apportées au c10k problem. Tout d'abord les cinq approches de gestion d'Entrées/Sorties proposées par Kegel sont expliquées: selon le type d'allocations de thread ainsi qu'en fonction des notifications et appels associés, ou bien en introduisant directement du code dans le noyau, ces solutions optimisent le service des requêtes client. En second lieu les solutions récemment sorties sont recensées et explorées. En solution d'actualité ressort le langage Erlang, avec ces deux implémentations phares: celle de Mochiweb puis de Yaws. Le nouveau concept de développement SEDA est également en vogue comme le démontre les comparaisons avantageuses qui ont été menées par rapport au fonctionnement du serveur web Apache. Enfin on termine cette section sur Node.js particulièrement adapté aux serveurs d'application réseau à haute performance et dont le moteur javascript GoogleChrome a pris le parti. La dernière partie 5 architecture des infrastructures web liste d'abord les implémentations de serveurs web qui rencontrent le plus de succès car légers, Open Source, et basés sur une architecture asynchrone non bloquante. L'architecture classique client-serveur est ensuite représentée dans ce quelle in*duit comme contention de ressources de traitement au niveau des serveurs Web. Enfin la mise à l'échelle de l'architecture web est vue en ultime point dans sa dimension de dilution du c10K problem. Elle montre que le dimensionnement d'équipements est un facteur clé pour gérer une énorme clientèle de machines permettant par exemple ainsi à un site comme ebay de maîtriser les gigantesques quantités d'accès sur son très populaire site de vente en ligne.

Premières propositions de critiques suite à la lecture de l'article C10k problem[modifier | modifier le code]

Structure points positifs[modifier | modifier le code]

Structure précise et logiquement articulée facile à réutiliser pour un résumé introductif.

Structure points négatifs[modifier | modifier le code]

Intérêt de séparer les parties Problématique et limites mécanismes ?
Introduire un schéma architecture dans la problématique mettant en exergue le bottleneck de la partie système d'exploitation.

Forme points positifs[modifier | modifier le code]

Je pense avoir compris le sujet et la forme a forcément participé. Notamemnt les schémas mais aussi les exemples cités.

Forme points Négatifs[modifier | modifier le code]

Peut être quelques lourdeurs dans le texte mais pas tant que ça finalement.
Références sont quasi toujours notées avec un N° de page. Le titre du paragraphe peut aussi être plus attrayant pour inciter le lecteur à aller consulter le texte cité.
libasync pourrait avoire une ref vers un article en + de la note.
Ref ↑ a et b D. Liu et Al. 2009, p. 3 pointe vers http://www.springerlinnk.com/§content/85xku4751816hu24/fulltext.pdf qui est un doc dont les pages sont 166–177, Bone Ref 2.1 p 168 ?

Fonds points positifs[modifier | modifier le code]

Bon exposé textuel de la problématique
Partie modèles thread-driven / event-driven => principes clairs
url en interne à la page (cf « SEDA (Staged event-driven architecture) »).

Fonds points négatifs[modifier | modifier le code]

Manque peut être un schéma présentant l'ensemble Client / réseau / serveur illustrant le goulot d'étranglement sur la partie système.
Donner un exemple d'actions et de jobs pour mieux comprendre les schémas.