En bref: vous devriez pouvoir réaliser de l' ordre de millions de connexions TCP actives simultanées et par extension de requête (s) HTTP. Cela vous indique les performances maximales auxquelles vous pouvez vous attendre avec la bonne plate-forme avec la bonne configuration.
Aujourd'hui, je m'inquiétais de savoir si IIS avec ASP.NET prendrait en charge dans l'ordre de 100 connexions simultanées (regardez ma mise à jour, attendez ~ 10k réponses par seconde sur les anciennes versions d'ASP.Net Mono). Quand j'ai vu cette question / réponses, je n'ai pas pu m'empêcher de me répondre, de nombreuses réponses à la question ici sont complètement incorrectes.
Meilleur cas
La réponse à cette question ne doit concerner que la configuration de serveur la plus simple à découpler des innombrables variables et configurations possibles en aval.
Considérez donc le scénario suivant pour ma réponse:
- Pas de trafic sur les sessions TCP, sauf pour les paquets keep-alive (sinon, vous auriez évidemment besoin d'une quantité correspondante de bande passante réseau et d'autres ressources informatiques)
- Logiciel conçu pour utiliser des sockets et une programmation asynchrones, plutôt qu'un thread matériel par requête d'un pool. (c.-à-d. IIS, Node.js, Nginx ... serveur Web [mais pas Apache] avec un logiciel d'application conçu par asynchrone)
- Bonnes performances / CPU dollar / Ram. Aujourd'hui, arbitrairement, disons i7 (4 cœurs) avec 8 Go de RAM.
- Un bon pare-feu / routeur pour correspondre.
- Pas de limite virtuelle / gouverneur - c.-à-d. Linux somaxconn, IIS web.config ...
- Aucune dépendance à un autre matériel plus lent - aucune lecture à partir du disque dur, car ce serait le plus petit dénominateur commun et le goulot d'étranglement, pas les E / S réseau.
Réponse détaillée
Les conceptions liées aux threads synchrones ont tendance à être les moins performantes par rapport aux implémentations d'E / S asynchrones.
WhatsApp obtient un million de trafic AVEC sur une seule machine OS à saveur Unix - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ .
Et enfin, celui-ci, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html , entre dans beaucoup de détails , explorant comment même 10 millions pourraient être atteints. Les serveurs ont souvent des moteurs de déchargement TCP matériels, des ASIC conçus pour ce rôle spécifique plus efficacement qu'un processeur à usage général.
Bons choix de conception de logiciels
La conception d'E / S asynchrones diffère selon les systèmes d'exploitation et les plates-formes de programmation. Node.js a été conçu dans un esprit asynchrone . Vous devriez utiliser au moins Promises, et quand ECMAScript 7 arrive, async
/ await
. C # /. Net a déjà un support asynchrone complet comme node.js. Quels que soient le système d'exploitation et la plate-forme, le système asynchrone devrait fonctionner très bien. Et quelle que soit la langue que vous choisissez, recherchez le mot-clé "asynchrone", la plupart des langages modernes auront un support, même s'il s'agit d'un module complémentaire.
Vers WebFarm?
Quelle que soit la limite de votre situation particulière, oui, une ferme Web est une bonne solution à la mise à l'échelle. Il existe de nombreuses architectures pour y parvenir. L'un utilise un équilibreur de charge (les fournisseurs d'hébergement peuvent les proposer, mais même ceux-ci ont une limite, ainsi qu'un plafond de bande passante), mais je ne suis pas favorable à cette option. Pour les applications à page unique avec des connexions de longue durée, je préfère plutôt avoir une liste ouverte de serveurs parmi lesquels l'application cliente choisira au hasard au démarrage et réutilisera pendant la durée de vie de l'application. Cela supprime le point de défaillance unique (équilibreur de charge) et permet la mise à l'échelle via plusieurs centres de données et donc beaucoup plus de bande passante.
Briser un mythe - 64K ports
Pour répondre à la question concernant «64 000», c'est une idée fausse. Un serveur peut se connecter à plus de 65535 clients. Voir /networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284
À propos, Http.sys sous Windows permet à plusieurs applications de partager le même port de serveur sous le schéma d'URL HTTP. Ils enregistrent chacun une liaison de domaine distincte, mais il n'y a finalement qu'une seule application serveur qui transmet les demandes aux applications appropriées.
Mise à jour 2019-05-30
Voici une comparaison à jour des bibliothèques HTTP les plus rapides - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext
- Date du test: 2018-06-06
- Matériel utilisé: Dell R440 Xeon Gold + 10 GbE
- Le leader a ~ 7 millions de réponses en texte brut par seconde (réponses et non connexions)
- Le second Fasthttp pour golang annonce 1,5 million de connexions simultanées - voir https://github.com/valyala/fasthttp
- Les principaux langages sont Rust, Go, C ++, Java, C et même C # se classant à 11 (6,9 millions par seconde). Scala et Clojure se classent plus bas. Python se classe au 29e rang à 2,7 millions par seconde.
- En bas de liste, je note laravel et cakephp, rails, aspnet-mono-ngx, symfony, zend. Tous en dessous de 10k par seconde. Notez que la plupart de ces frameworks sont construits pour des pages dynamiques et assez anciens, il peut y avoir des variantes plus récentes qui figurent plus haut dans la liste.
- N'oubliez pas qu'il s'agit de texte en clair HTTP, pas pour la spécialité Websocket: de nombreuses personnes qui viennent ici seront probablement intéressées par des connexions simultanées pour websocket.