(Communément appelé le problème C10K)
Existe-t-il une revue plus contemporaine des solutions au problème c10k (Dernière mise à jour: 2 septembre 2006), spécifiquement axée sur Linux (epoll, signalfd, eventfd, timerfd ..) et des bibliothèques comme libev ou libevent?
Quelque chose qui traite de tous les problèmes résolus et toujours non résolus sur un serveur Linux moderne?
Le C10K problème suppose généralement que vous essayez d'optimiser un serveur unique, mais que votre article référencé points de "le matériel n'est plus le goulot d'étranglement". Par conséquent, la première étape à prendre est de s'assurer que ce n'est pas la plus simple et la moins coûteuse il suffit de jeter plus de matériel dans le mélange.
Si nous avons obtenu une valeur de 500 $de la boîte de servir les clients X par seconde, c'est beaucoup plus efficace de simplement acheter un autre de 500 $de la boîte à double débit au lieu de laisser un employé engloutir qui sait combien d'heures et de dollars à essayer de comprendre comment profiter davantage de la boîte d'origine. Bien sûr, c'est en supposant que notre application est multi-serveur sympathique, que nous savons comment équilibrer la charge, etc, etc...
Par coïncidence, il y a quelques jours, la Programmation Reddit ou peut-être Hacker News mentionné cette pièce:
Des milliers de Fils et de Blocage IO
Dans les premiers jours de Java, ma programmation en C des amis se moquaient de moi pour faire socket IO avec le blocage des threads; à l'époque, il n'y avait pas d'alternative. Ces jours-ci, avec une abondante mémoire et de processeurs, semble être une stratégie viable.
L'article est daté de 2008, de sorte qu'il tire de votre horizon par un couple d'années.
Pour répondre à l'OP de la question, on pourrait dire qu'aujourd'hui l'équivalent de document n'est pas à propos de l'optimisation d'un serveur unique pour la charge, mais l'optimisation de l'ensemble de votre service en ligne pour la charge. De ce point de vue, le nombre de combinaisons est tellement grand que ce que vous cherchez n'est pas un document, c'est un site qui recueille des architectures et des cadres. Un tel site existe et elle s'appelle www.highscalability.com
Note 1:
J'avais à l'encontre de la croyance que de jeter plus de matériel, c'est une solution à long terme:
Peut-être le coût d'un ingénieur qui "reçoit" le rendement est élevé par rapport au coût d'un seul serveur. Ce qui se passe quand vous évoluer? Disons que vous disposez de 100 serveurs. 10 pour cent d'amélioration dans la capacité du serveur peut vous épargner des 10 serveurs par mois.
Même si vous avez seulement deux machines, vous avez encore besoin pour gérer les pointes de performance. La différence entre un service qui se dégrade gracieusement sous charge et un qui se décompose, c'est que quelqu'un a passé du temps à optimiser pour le scénario de charge.
Remarque 2:
L'objet de ce post est un peu trompeur. Le CK10 document n'essayez pas de résoudre le problème de 10k clients par seconde. (Le nombre de clients par seconde n'est pas pertinent, sauf si vous définissez également une charge de travail avec débit soutenu délimitée en vertu de la latence. Je pense que Dan Kegel était conscient de cela quand il écrit que la doc). Regardez plutôt comme un recueil d'approches en matière de renforcement simultané des serveurs, et des micro-benchmarks pour la même chose. Peut-être ce qui a changé entre hier et aujourd'hui c'est qu'on peut supposer à un point de temps que le service était pour un site web qui a servi de pages statiques. Aujourd'hui, le service pourrait être un magasin de données noSQL, une cache, un proxy ou de l'une des centaines de logiciels d'infrastructure réseau morceaux.
Vous pouvez également prendre un coup d'oeil à cette série d'articles:
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3
Il montre une bonne quantité de données sur le rendement et le système d'exploitation configuration de travail qu'il avait à faire pour soutenir les 10K et puis 1M connexions.
Il semble comme un système avec 30 GO de RAM peut gérer 1 million de clients connectés sur une sorte de réseau social type de simulation, à l'aide d'un libevent frontend pour un Erlang application basée sur serveur.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
