Combien de connexions possibles?

Question

Quelqu'un at-il une idée du nombre de connexions tcp-socket possibles sur un serveur racine standard moderne? (En général, il y a moins de trafic sur chaque connexion, mais toutes les connexions doivent être activées en permanence.)

MODIFIER: nous utiliserons un serveur Linux.

Answer 1

Google autour pour le " C10K " problème. C’est en gros une discussion et une technologie autour de la gestion de 10 000 connexions simultanées ou plus.

Je soupçonne que ce nombre a été choisi parce que c'est difficile, mais théoriquement possible.

Answer 2

J’ai atteint 1600 000 connexions de socket inactives simultanées et, simultanément, 57 000 req / s sur un poste de travail Linux (16G de RAM, I7 2600 CPU). C'est un serveur http à simple thread écrit en C avec epoll. Le code source se trouve sur github , un blog ici .

Modifier:

J'ai effectué 600 000 connexions HTTP simultanées (client et serveur) sur le même ordinateur, avec JAVA / Clojure. informations détaillées post , discussion HN: http://news.ycombinator.com/item?id=5127251

Le coût d'une connexion (avec epoll):

• application nécessite de la RAM par connexion
• Tampon TCP 2 * 4k ~ 10k ou plus
• epoll a besoin de mémoire pour un descripteur de fichier, à partir de epoll (7)

  

Chaque descripteur de fichier enregistré coûte environ 90                 octets sur un noyau 32 bits et environ 160 octets sur un noyau 64 bits.

Answer 3

Cela dépend non seulement du système d'exploitation en question, mais également de la configuration, éventuellement de la configuration en temps réel.

Pour Linux:

cat /proc/sys/fs/file-max

indiquera le nombre maximum actuel de descripteurs de fichiers total autorisé à être ouvert simultanément. Découvrez http://www.cs.uwaterloo.ca/~brecht/servers /openfiles.html

Answer 4

10 000? 70 000? est-ce tout:)

FreeBSD est probablement le serveur que vous voulez, voici un little article de blog sur le réglage permettant de gérer 100 000 connexions, il propose depuis quelque temps des fonctionnalités intéressantes, telles que les sockets zéro copie, ainsi que kqueue pour servir de mécanisme de port d'achèvement.

Solaris peut gérer 100 000 connexions au cours du siècle dernier. ! Ils disent que Linux serait mieux

La meilleure description que j’ai rencontrée est cette présentation / papier sur l’écriture d’un serveur Web évolutif. Il n'a pas peur de le dire comme ça:)

  

Idem pour le logiciel: les crétins sur le   couche d'application forcée grande   innovations sur la couche OS. Parce que   Lotus Notes conserve une seule connexion TCP   par client ouvert, IBM a contribué   optimisations pour le processus "One",   100 000 connexions ouvertes & # 8221; cas à Linux

     

Et le planificateur O (1) était à l'origine   créé pour bien marquer sur certains   référence Java non pertinente. Le fond   la ligne est que ce ballot bene & # 64257; ts tous   nous.

Answer 5

Sous Linux, vous devriez envisager d’utiliser epoll pour les E / S asynchrones. Cela vaut également peut-être la peine d’affiner le tampon de socket pour ne pas gaspiller trop d’espace noyau par connexion.

Je suppose que vous devriez pouvoir atteindre 100 000 connexions sur une machine raisonnable.

Answer 6

Une limite du nombre de sockets ouverts est configurable dans le système de fichiers / proc

cat /proc/sys/fs/file-max

Nombre maximal de connexions entrantes dans le système d'exploitation défini par des limites entières.

Linux lui-même autorise des milliards de sockets ouverts.

Pour utiliser les sockets, vous avez besoin d'une application à l'écoute, par exemple. un serveur Web, et qui utilisera une certaine quantité de RAM par socket.

La RAM et la CPU introduiront les limites réelles. (2017 moderne, pensez des millions pas des milliards)

1 million est possible, pas facile. Attendez-vous à utiliser X gigaoctets de RAM pour gérer 1 million de sockets.

Les connexions TCP

sortantes sont limitées par des numéros de port ~ 65 000 par IP. Vous pouvez avoir plusieurs adresses IP, mais pas des adresses IP illimitées. C’est une limite en TCP et non en Linux.

Answer 7

dépend de l'application. s'il n'y a que quelques paquets de chaque client, 100K est très facile pour Linux. Un ingénieur de mon équipe a fait un test il y a plusieurs années. Le résultat montre que, lorsqu'il n'y a plus de paquet du client après la connexion, linux epoll peut regarder 400k fd pour une lisibilité au niveau d'utilisation du processeur inférieur à 50%.

Answer 8

Quel système d'exploitation?

Pour les machines Windows, si vous écrivez un serveur pour qu'il s'adapte correctement et que vous utilisiez par conséquent des ports de complément d'E / S et des E / S asynchrones, la principale limitation est la quantité de pool non paginée que vous utilisez chaque connexion active. Cela se traduit directement par une limite basée sur la quantité de mémoire installée par votre machine (le pool non paginé est une quantité finie à taille fixe qui dépend de la mémoire totale installée).

Pour les connexions qui ne voient pas beaucoup de trafic, réduisez-les et améliorez leur efficacité en postant des "lectures de zéro octet" qui n'utilisent pas de pool non paginé et n'affectent pas la limite de pages verrouillées (une autre ressource potentiellement limitée qui vous empêcher d’avoir beaucoup de connexions de socket ouvertes).

En dehors de cela, vous aurez besoin d'un profil, mais j'ai réussi à obtenir plus de 70 000 connexions simultanées sur un serveur modeste (mémoire de 760 Mo); voir ici http://www.lenholgate.com/ blog / 2005/11 / windows-tcpip-server-performance.html pour plus de détails.

Évidemment, si vous utilisez une architecture moins efficace, telle que "thread par connexion" ou "select", vous devriez vous attendre à des résultats moins impressionnants. mais, à mon humble avis, il n’ya tout simplement aucune raison de choisir de telles architectures pour les serveurs Windows Sockets.

Modifier: ( http://blogs.technet.com/ markrussinovich / archive / 2009/03/26 / 3211216.aspx ; la manière dont le montant du pool non paginé est calculé a changé dans Vista et Server 2008 et il en existe désormais beaucoup plus.

Answer 9

En réalité, pour une application, plus de 4000 à 5000 prises ouvertes sur une seule machine deviennent irréalisables. Le simple fait de vérifier l’activité de tous les sockets et de les gérer commence à devenir un problème de performances, en particulier dans les environnements en temps réel.