Discussion:C10k problem

Cet article est indexé par le projet Sécurité informatique.

Les projets ont pour but d’enrichir le contenu de Wikipédia en aidant à la coordination du travail des contributeurs. Vous pouvez modifier directement cet article ou visiter les pages de projets pour prendre conseil ou consulter la liste des tâches et des objectifs.

Évaluation de l’article « C10k problem »

Avancement	Importance	pour le projet
B	Élevée		Sécurité informatique (discussion • critères • liste • stats • hist. • comité • stats vues)

Cet article ne comporte pas de liste de tâches suggérées. Vous pouvez saisir une liste de tâches à accomplir (par exemple sous forme d'une liste à puces), puis sauvegarder. Vous pouvez aussi consulter la page d'aide.

Bonjour,

J'attire votre attention sur les problèmes de mise en forme suivants :

1. L'usage de <span style="color:#0000f1">...</span> est à proscrire. De façon générale, évitez systématiquement les « mises en formes originales » (couleurs, fontes, jeu sur les tailles de polices...)  ;
2. Dans le même esprit, n'utilisez pas les balises <br/>. Rédigez des paragraphes, et séparer vos paragraphes par une ligne vide. N'utilisez pas de caractères spéciaux tel que → pour faire des listes à puces. Les items d'une liste à puce sont obtenue en commençant la ligne par un caractère * (** si vous voulez faire des sous items, *** pour des sous-sous items...). De même pour faire des listes numérotées commencez chaque ligne de la liste par un # (## pour des sous-listes, ### pour des sous-sous listes...) ;
3. Pensez à « wikifier » votre document. Lorsque vous citez des éléments technologiques liés à votre article, comme le langage Erlang, placez un lien vers l'article relatif à ce langage : Erlang (langage). Vous pouvez simplement créer ce lien en écrivant le nom de l'article entre double crochet : [[Erlang (langage)]] , ou, si vous désirez associer l'article à un mot particulier, par exemple à Erlang, utilisez la syntaxe :«  [[Erlang (langage)|Erlang]]  », ce qui donne, à l'affichage : Erlang ;
4. Respectez le modèle de référence de harvard tel que préconisé par Wikipédia. C'est-à-dire, a minima, pour chaque référence, donnez : « <identité du premier auteur>, <année de publication de l'ouvrage>, <localisation dans le texte> », et liez les 2 premiers items à une entrée bibliographique complète en utilisant les modèles tel que {{ouvrage}}, {{article}} ou encore {{Lien web}} (prenez l'exemple donné dans l'introduction). Le trosième item est important, typiquement, il s'agit du numéro de page qui contient l'information pointé  ;
5. Pensez à illustrer votre propos. L'utilisation de schémas, sous la forme d'images, de tableaux ou encore d'extraits d'algorithmes peut aider le lecteur à suivre votre propos, parfois assez hermétique.

Gilles.Grimaud (d) 3 mai 2011 à 16:35 (CEST)Répondre

J'attire votre attention sur le fait que les références ne doivent pas servir à identifier les technologies que vous citez, mais vos affirmations.

Par exemple, On lit dans le texte : « On peut citer les implémentations de serveurs Web basés sur Erlang^[15], ... ». Ici, la référence [15] doit permettre de vérifier que le langage Erlang a été utilisé pour implémenter différents serveurs Web. Ce n'est pas le cas dans le texte actuel. La référence [15] pointe simplement vers le site web du langage Erlang. Cette référence est inutile. Faire pointer la référence [15] vers un serveur web implémenté avec le langage Erlang ne résoudrait pas le problème. Cela pourrait être taxé de Travail inédit, puisqu'il s'agirait d'une source primaire. La référence attendu ici doit être un document technique ou scientifique qui affirme qu'il existent un certain nombre d'implémentation de serveurs web basés sur Erlang, ou que Erlang permet d'implémenter des serveurs web.

De plus, il est essentiel de baser votre état de l'art sur des sources de qualité. Privilégiez les articles scientifiques publiés dans des conférences ou des journaux avec comités de lecture. En l'état, le document fait trop de référence à des sources dont la qualité peu être « contestée » (blog, flux vidéos...). A ce propos, j'attire votre attention sur le fait qu'un article wikipédia ne peut jamais être utilisé comme source (évidement!).

En l'état les quelques entrées bibliographiques (très insuffisantes) sont très incomplètes. Il convient de préciser la liste complète des auteurs, la date de parution, le journal scientifique dans lequel est paru l'article, et un lien vers le document s'il est disponible sur le web. Veillez, autant que possible à compléter les champs des modèles {{article}} ou {{ouvrage}} que vous utilisez.

Gilles.Grimaud (d) 3 mai 2011 à 16:30 (CEST)Répondre

A propos du plan, Je n'ai pointé les sections qu'à titre d'exemple. Je vous encourage à organiser le plan à votre convenance. Une section "Historique" serait par exemple là bienvenue.

Gilles.Grimaud (d) 3 mai 2011 à 16:48 (CEST)Répondre

Question à Gilles Grimaud:

Abordé les différentes architectures des plates-formes web dans le C10k problem, est-ce hors sujet ? ou pas ? Doit-t-on approfondir cette piste en parlant de la scalabilité, des éléments de répartition de charge, etc... Ou est-ce une perte de temps !? Merci

De manière générale ? sommes nous dans le sujet ?

Bonjour,

Cela peut sembler une bonne piste de développement du sujet, si vous trouvez des références qui expliquent en quoi cette stratégie est pertinente pour dépasser les 10000 connexions. Sinon, non.

Je profite de ce message pour vous attirer votre attention sur le fait que la problématique du c10k problem n'as pas encore été développé, et qu'une historique du problème et des solutions proposées serait aussi la bienvenue.

Le problème le plus critique, à mes yeux, et le fait que vous ne sourcez pas vos affirmations. C'est pourtant précisément le but de l'exercice. Lorsque vous affirmer quelque chose, vous devriez citer la source qui corrobore votre affirmation. Le plus souvent vous citez la page web technologie dont vous parlez, mais pas ce qui vous permet d'affirmer qu'elle fait ce que vous dites... voir exemple précédent.

PS : pensez à signer vos message sur la page de discussion avec ~~~~

Gilles.Grimaud (d) 6 mai 2011 à 16:23 (CEST)Répondre

Bonjour,

Vous pointez des lien web lorsque cela n'a pas de sens : par exemple dans : « Plusieurs serveurs web légers^[37]... »

Donnez la véritable référence et pas un résultat de recherche google !

Utilisez le modèle article {{article}}. Indiquez le titre, en l'occurence : "Monitoring and State Transparency of Distributed Systems Martin Logan, Futuresource", l'auteur : "Martin Logan", le journal : "proceedings of ACM SIGPLAN Erlang Workshop" année 2004, mois septembre, jour 22... et la page que vous citez : ???. Il en va de même pour le lien vers l'article : http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.116.1969&rep=rep1&type=pdf, il s'agit d'un article de Joe Armstrong, publié dans "proceedings of Lightweight Languages Workshop 2002 (LL2)" sous le titre "Concurrency Oriented Programming in Erlang" ...

Les seuls lien web qui sont acceptables sont ceux qui références un "site web officiel" représentant la technologie dont vous parlez.

Distinguez les entrées de type RFC/IETF et norme des entrées de type articles et ouvrages (prenez exemple sur la mise en forme de la bibliographie de l'article 6LoWPAN pour ca).

Gilles.Grimaud (d) 10 mai 2011 à 11:24 (CEST)Répondre

Il ne doit y avoir aucun Lien vers une URL en guise de référence! vous donnez par exemple le lien suivant : http://portal.acm.org/citation.cfm?id=502057 en guise de référence. Il s'agit d'un article! il a des auteurs : "SEDA: an architecture for well-conditioned, scalable internet services".

Par ailleurs, vous n'avez pas le droit de charger des images qui ne sont pas à vous dans wikipédia. évidement. Pour illustrer votre article, il vous faudra produire vous même les images que vous utiliserez.

Gilles.Grimaud (d) 10 mai 2011 à 16:27 (CEST)Répondre

Vos références ne sont toujours pas complètement satisfaisante. Au lieu d'utiliser les balises <Ref>...</ref> dans le texte, utilisez le modèle {{harvsp}} (suivez le lien pour comprendre l'usage).

Merci de re-formater en conséquence.

Gilles.Grimaud (d) 10 mai 2011 à 18:47 (CEST)Répondre

Bonjour,

Je relis l'article et vous rapporte ici mes commentaires sur le plan, la forme et le fond.

J'ai du mal à distinguer, au fond, le contenu du chapitre 4 et 5. Ne pourraient-il pas être groupés ? Pour le reste, le plan me semble couvrir le sujet, et il me parait pertinent.

Anglicismes

Vous faites volontiers usage d'anglicismes, et il est vrai que le titre même de l'article s'y prête. Ceci étant dit, vous pouvez constater, que pour le titre, des la mise en évidence du terme, une note indique l'interprétation qu'il faut donner à ces mots, en français. De la même manière, je pense qu'il convient, pour chaque terme anglais, d'en donner une définition en français. Après-tout, vous avez choisi de contribué en français. De plus, lorsque vous utilisez des mots qui ne sont pas en français, veillez à les mettre en italique. Parmi ces anglicismes je pense surtout à : thread-driven, event-driven, mais aussi à des mots moins évident pour l'informaticien, comme header (on écrit en-tête en français), I/O (on parle d'Entrées-sorties en français), et tant d'autres...

« wikification »

L'article, en l'état, ne fait pas assez de liens vers d'autres articles. Cela est tout de même bien pratique pour comprendre de quoi vous parlez exactement.

mise en forme

évidez la mise en forme "à la main" de votre document. Utilisez les * pour faire des listes, les # pour faire des listes numérotées, les === sous-titres === et ==== sous-sous-titres === pour décomposer votre plan. Toute mise en forme singulière et déstabilisante pour le lecteur, et malvenue. Dans le même esprit, ne sautez pas des lignes en cascade. Les sauts de lignes (1 ligne) servent seulement à marquer la fin d'un paragraphe.

l'orthographe

Comme vous l'avez vu, un wikipédiste (pas moi) a jugé bon d'ajouter une bannière pour indiquer que cet article à de sérieux problème d'orthographe. C'est un point à améliorer pour la lisibilité.

Sur le fond, l'article est encore incomplet donc difficile à évaluer.

sur la partie problématique

un effort peu encore être fait pour mettre en évidence la source des problèmes rencontrés, et les familles de solutions envisageables.

sur la partie historique

Je m'attends, dans cette partie, à comprendre quand le problème a été identifié, et comment se sont enchainé les différentes étapes des solutions qui y ont été apportée. Ce n'est pas ce que je trouve dans le texte, pour l'instant. Il me semble qu'une présentation plus chronologique des événements serait la bienvenue.

La fin du document me semble aller dans la bonne direction (des développements restent à donner, bien-sur).

En conclusion, le travail commence à porter ces fruits. Vous êtes sur la bonne voie.

Gilles.Grimaud (d) 11 mai 2011 à 13:22 (CEST)Répondre

Bonjour,

Vous avez tendance à mettre plusieurs fois le lien vers un concept. Par exemple pour Thread, Une fois que vous l'avez donné en lien, inutile d'y revenir cent fois dessus... non ?

Gilles.Grimaud (d) 12 mai 2011 à 17:58 (CEST)Répondre

Bonsoir,

Il subsiste un dernier problème de mise en forme dans vos références Harvard, par rapport à ce que j'attends précisément. Le principe est de mettre une simple référence de la forme ^[3]" qui renvoi à la description harvard, en bas de page. Pour faire cela il suffit d'encadrer à par des balises<ref name="ref_name">{{ma référence}}</ref>) la référence harvard. Cela à le mérite de ne pas polluer le texte avec des références, mais les renvoyer en bas de page (dans la section "référence", précisément). Ceci étant dit, les parenthèse du modèle modèle harvard {{Harv}} n'ont alors plus d'utilité (une fois en base de page). Je vous avez donc conseillé d'utiliser {{harvsp}} (sp pour "sans parenthèse"). Ensuite, j'attire votre attention qu'il convient d'indiqué le numéro de page par un p="mon numéro de page" et non en écrivant "page 2" par exemple. et pour finir, chaque référence harvard doit être liée à son entrée bibliographique, et le plus simple pour cela est d'utiliser le champ id="id de l'entrée bibliographique". Ce qui donne par exemple, au final : <ref name=Lauer_1979_2>{{Harv | Hugh C. Lauer et Roger M. Needham|1979|p=2|id=Lauer1979}}</ref>.

J'ai fait un exemple pour illustrer mon propos, observez ce diff.

merci de reporter ce modèle sur tout le texte (J'en profite pour attirer votre attention sur le fait que des références actuellement en références ne respectent pas le modèle harvsp...).

Sinon le document commence à converger vers un contenu satisfaisant. A ce propos, la section "La gestion des entrées-sorties" n'est absolument pas sourcée... A sourcer donc.

Gilles.Grimaud (d) 13 mai 2011 à 01:36 (CEST)Répondre

Bonjour,

Je sais qu'il s'agit là d'une requête casse-pied, mais il vous faut trouver des illustrations pour rendre plus digeste la lecture de ce document :

• dans la section "problématiques" des illustrations pourraient facilité la compréhension des différents modèles.
• dans la section "technologies existantes" ou vous pouvez mettre les logos de quelques unes des technologies dont vous parlez et des diagrammes de séquences ou des algorithmes illustrant l'usage des primitives expliquées par exemple.
• Vous pouvez surtout extraire dans un tableur les valeurs numériques des figures que vous trouvez dans des articles de références et générer un diagramme.

En faisant ça, vous n'aurez pas de problème de copyvio et cela pourrait aider à comprendre la problématique (je pense à ce type de figures). Cela aèrera le texte, sans "tricher" (en insérant des sauts de lignes injustifiés).

Par ailleurs, je vous conseille de mettre les fonctions systèmes et de façon général le code, comme le prévoit WP, c'est à dire, entre des balises <code>MaFonction()</code>, qui donne, en rendu : MaFonction(). Cela contribue aussi à facilité la lecture du texte. Je pense par exemple aux occurrences de read(), poll(), select(), ... et bien d'autres.

Dans le même esprit, il est conseillé de mettre systématiquement les mots anglais en italiques (et de les éviter).

Notez aussi que je désapprouve l'usage de [[:en:Examples]] qui donne en:Examples, pour référencer une page en anglais, cela parce que vous n'avez pas trouvé la version francophone. Écrivez plutôt {{lien|langue=en|trad=Examples}} qui donne : Examples (en). Certes cela donne un lien en rouge, mais cela indique clairement au lecteur que l'article en question n'existe pas en français mais qu'on peu le lire sur le wikipédia anglophone (lien (en)). Et le jour ou l'article est créé en français, le lien prend la forme d'un lien classique vers le wikipédia francophone...

A propos des références, ne reportez pas tout les prénom/nom dans la référence. Elles sont redondantes avec l'entrée bibliographique. pour l'exemple, j'ai transformé {{Harvsp |James C. Hu, Irfan Pyarali et Douglas C. Schmidt|1997|p=1|id=Hu1997}} en {{Harvsp |C. Hu et Al.|1997|p=1|id=Hu1997}} (et Al. indiquant qu'il n'était pas seul). Cela rend la table des références moins indigestes.

Enfin, j'ai noté que vous avez utilisé des tournures non neutre (nous... vous...), en l’occurrence vous avez écrit : "Notons". Ces tournures sont malvenues dans un état de l'art qui se veut descriptif et qui ne doit pas prendre à partie le lecteur.

Gilles.Grimaud (d) 13 mai 2011 à 12:39 (CEST)Répondre

Bonjour,

Je suis tombée par hasard sur ces 4 articles écrits apparemment par des étudiants. J'ai relu ce qui a été écrit pour aider la mise en forme des pages. Voici ce que je vous conseille :

• Je n'y ai pas touché mais il ne faut pas numéroter les figures. Les labels des figures doivent « parler d'eux-même ». Il ne faut pas oublier que Wikipédia est une encycopédie publique. Dans l'avenir, si quelqu'un d'autre ajoute une figure, il ne faudra pas qu'il galère à rechanger toutes les numérotations des figures etc. Ce n'est pas pratique.
• Il ne faut pas « expliquer une histoire », surtout que les articles que vous écrivez sont des articles scientifiques et donc « facilement » référençables. Vous pouvez consulter la page du style à utiliser.
• Il ne faut pas compliquer la mise en forme avec des « br », des sauts de lignes etc. Cela ne fait que rendre plus difficile le travail de la personne qui voudra contribuer après vous. Baub (d) 14 mai 2011 à 18:02 (CEST)Répondre

Bonjour,

J'ai encore des remarques à propos des références. Vous avez plusieurs fois, dans l'article actuel placé des liens vers des pages "externes", comme par exemple pour : Richard Jones, « A Million-user Comet Application with Mochiweb, Part 1 », www.metabrew.com, 2008, « Mochiweb », Ali Ghodsi, « Apache vs. Yaws », www.sics.se, 2008, etc.

Vous ne devez pas directement citer vos sources ainsi. Lorsque vous référencez un site web, cela doit être dans la section "Liens externes", et cela doit être la page d’accueil du site web.

par exemple :

N'écrivez pas :

Il fait partie des logiciels fournis avec la livraison Fedora.

mais, écrivez :

Il fait partie des logiciels fournis avec la livraison Fedora^{[exemple 1]}.

[...]

[...]

• « site officiel de la communauté fedora », Fedora (consulté le 16 mai 2011)

J'ai corrigé la mise en forme de cette référence dans votre texte, merci de faire de même avec tous les autres liens http de votre document, pour que la mise en forme soit irréprochable. Notez bien que dans la référence est de la forme :

• « titre de la page web » sur site officiel de référence

Gilles.Grimaud (d) 16 mai 2011 à 17:53 (CEST)Répondre

Bonsoir,

Votre texte a atteint un degrés de maturité suffisant. Il serait bon, néanmoins de créer des entrés dans la section "liens externes" avec les références vers des sites web que vous avez laissé sous la forme d'une URL dans la section référence. Je me permet simplement de vous inviter à une relecture lorsque vous en aurez le temps. Vous pourrez alors notamment mettre des liens vers les articles wikipédia aux endroits opportuns pour faciliter la lecture. Je relèverais les documents à dimanche 22 à minuit.

A bientôt,

Gilles.Grimaud (d) 17 mai 2011 à 02:24 (CEST)Répondre

Je viens de parcourir votre section "Problématique" et la section "Historique" et de relever les références manquantes et d'autres petits problèmes. Consultez le texte pour voir mes remarques. Je note aussi, qu'en l'état, la section Historique est incomplète. A moins que plus rien ne se soit passé depuis 2002 ? ! Enfin, je note un petit problème d'organisation dans la section "Limites des mécanismes standards". En effet, la première partie de cette section, jusqu'à Limitations, n'est ne traite pas des Limites, mais elle présente la "la gestion des entrées-sorties (en mode asynchrone)". Cette présentation devrait être faite dans la sous-section "La gestion des entrées-sorties" (Asynchrones). La section "Limites des mécanismes standards" ne devrait parler que de la... limite des mécanismes standards.

Gilles.Grimaud (d) 18 mai 2011 à 12:48 (CEST)Répondre

Bonjour Nous avons essayé de compléter le plus possible les références manquantes, par contre il doit en rester 3 pour lesquelles nous n'avons pas retrouvé la source. Doit on supprimer le texte malgré l'intéret de celui ci ou peut on le laisser malgré cela ? Fabrice

--Fmaison (d) 22 mai 2011 à 15:17 (CEST)Répondre

• 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.

Tout d'abord bravo pour la rédaction de cet article qui nous a vraiment bien éclairé sur la nature du problème. Nous vous présentons ici quelques critiques que nous espèrons constructives même si notre avis n'est pas le plus expert dans le domaine.

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

• 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.
• D'après LB le document aurait gagné a étre structuré en fonction des OS UNIX/Linux et Windows(cet OS là n'est quasiment pas présent).
• Il manque une partie qui liste les différents protocoles impactés: l n'est question que de protocole http, est-il le seul impacté par C10k, ou y-a-t-il d'autres protocoles impactés
• Le document va très vite dans le particulier ou dans le détail.
• Le plan pourrait avoir une meilleure organisation : l'historique est au milieu de l'article, "les limites des mécanismes standards" est une partie qui pourrait 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". si l'historique était placé en fin de document on comprendrait les notions qui ont déjà été abordées dans les précédentes parties..

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.

• Je pense avoir compris le sujet et la forme a forcément participé. Notamemnt En général l'article est lisible, compréhensible. La neutralité de la forme est généralement respectée notamment dans la manière de notifier les références.

• Il y a une bonne volonté de présenter des schémas mais ils devraient êtres soit plus explicites soit plus commentés.
• 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 ?

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

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].

"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.

• Peut être quelques lourdeurs dans le texte mais pas tant que ça finalement.Pour exemple à plusieurs reprises des phrases trops longues nuisent à la compréhension du sujet. Chapitre "Problématique" la phrase "La démocratisation de l'internet .... " fait 5 lignes ! Idem dans le chapitre "Limites de mécanismes standards" la phrase "Certaines limitations .... " fait 4 lignes !

• 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 v un doc dont les pages sont 166–177, Bonne Ref 2.1 p 168 ?

• Le document est complet car l'historique nous amène jusqu'en 2010
• 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) »).
• 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.

• 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.
• 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.
• Aucune partie ne remet en cause le fait qu'il existe toujours une limite C10k, son concept, ont-il été remis en question dans la communauté informatique ?
• "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 ?