Discussion :

[mercyril]

Bonjour,

N'étant pas expert sur le développement d'application serveur à forte charge, je vous porte une réflexion autour du concept d'un serveur vers plusieurs milliers de clients.

A l'heure actuelle, j'ai un serveur pouvant accepter plusieurs clients.
J'ai choisi de n'utiliser qu'un seul thread pour gérer l'ensemble de mes clients connectés par le biais d'un liste chainée. Chaque nouvelle connexion crée un élément supplémentaire dans ma liste et chaque déconnexion en retire un.
Ensuite, j'utilise le couple select()/FD_ISSET() en parcourant ma liste chainée pour déterminer quel client envoi un message.

Ma réflexion :
Je vais avoir une montée en charge sur le nombre de clients, plusieurs milliers sur un seul serveur, à l'heure actuelle j'en ai une centaine max.
La solution déjà mise en place (une liste chainée dans un seul thread) n'ira pas, le temps pour parcourir la liste chainée avec un FD_ISSET() pour déterminer quel client envoi un msg n'est pas viable avec plusieurs milliers de clients.

J'envisage une solution utilisant une dizaine de threads dédiés aux sockets clientes.
Chaque thread gère alors une liste chainée de 1000 sockets max (1000x10 = 10000 clients max pour l'application).
Un nouveau thread gère la répartition des clients sur la 10aine de thread dédiées aux sockets clientes.

Cette architecture réponds à mon besoin, mais comment auriez-vous fait pour manager 10000 clients (ou plus) sur un seul serveur ?

[gangsoleil]

Bonjour,

Deja, j'utiliserai des tableaux plutot que des listes chainees, mais c'est un avis perso (il y a des pour et des contre dans les deux cas).

Apres, ca depend de l'activite : est-ce qu'elle est faible, ou bien est-ce que tu recois des donnees en permanence partout ? Et que fais-tu des donnees ?

Si tu recois des donnees en permanence et que tu dois les stocker, alors un thread pour 1000 connexions est probablement insuffisant.
Si tu recois 2 donnees toutes les 10 minutes, et que tu dois juste les analyser pour je ne sais quoi, alors un thread pour 1000 connexions est plus que suffisant.

Enfin, une fois que tu auras ton archi de thread, en utiliser 5 ou 50, ca ne demandera pas beaucoup d'adaptation.

[DrDarko]

Bonjour,

Je pense que les listes chainées seront plus avantageuses sur la gestion des ajouts et des suppressions d'éléments par rapport à un tableau.

Par exemple s'il doit supprimer la case 500 de son tableau de 1000 après il doit décaler tout son tableau, alors que s'il utilise les listes chainées il a juste à manipuler 2 pointeurs dans le cas d'une liste doublement chainée.

[mercyril]

Deja, j'utiliserai des tableaux plutot que des listes chainees, mais c'est un avis perso (il y a des pour et des contre dans les deux cas).

J'ai pris la liste chainée pour la raison évoquée par DrDarko.

Apres, ca depend de l'activite : est-ce qu'elle est faible, ou bien est-ce que tu recois des donnees en permanence partout ? Et que fais-tu des donnees ?

Si tu recois des donnees en permanence et que tu dois les stocker, alors un thread pour 1000 connexions est probablement insuffisant.
Si tu recois 2 donnees toutes les 10 minutes, et que tu dois juste les analyser pour je ne sais quoi, alors un thread pour 1000 connexions est plus que suffisant.

L'activité peut être soutenue par moment, même si le débit peut être considéré comme faible. Les clients peuvent être connecté assez longtemps, sans émettre en permanence, d'où cette quantité de connexions simultanées possible (10000).
Il y a stockage dans une base de données via un autre thread dédié

Enfin, une fois que tu auras ton archi de thread, en utiliser 5 ou 50, ca ne demandera pas beaucoup d'adaptation.

Oui ca c clair

Merci pour vos réponses

[gangsoleil]

Je fais la chose suivante :
J'ai un tableau de potentielles sockets. La cellule 0 contient la master socket (la connexion principale), et les autres cellules les id des sockets ouvertes. Les cases vides contiennent -1 (id non valable pour une socket).
Je parse mon tableau a coup de FD_ISSET, et je traite si le resultat est positif.
Si j'arrive a une cellule contenant -1, je sais que j'ai atteint la fin du tableau.
Je n'ai plus qu'a intervertir les dernieres cellules du tableau avec les cases des sockets qui ont ete fermees, s'il y en a (3 ecritures d'entier en acces direct : -1 lors de la fermeture, copie du numero de la socket, puis -1 dans la derniere case).

[Jean-Marc.Bourguet]

Enfin, une fois que tu auras ton archi de thread, en utiliser 5 ou 50, ca ne demandera pas beaucoup d'adaptation.

C'est pas utile avec son architecture d'avoir beaucoup plus de thread que de cores.

Plutot que select ou poll, il arrive un moment ou il faut envisager d'utiliser des choses specifiques a la plateforme (/dev/poll sous Solaris, epoll sous Linux, il me semble que certains BSD ont quelque chose de dimilaire) qui evite une recherche en O(N) pour trouver le fd sur quoi il y a de l'activite.

Une autre piste est de n'avoir qu'une thread qui fait le select mais passe les fd sur lesquels il faut agir aux autres threads, comme ca il y a moins de risque que toute l'activite se passe sur les fd d'une thread donnee en gardant les autres bloquees sur le select.

[mercyril]

Je fais la chose suivante :
J'ai un tableau de potentielles sockets. La cellule 0 contient la master socket (la connexion principale), et les autres cellules les id des sockets ouvertes. Les cases vides contiennent -1 (id non valable pour une socket).
Je parse mon tableau a coup de FD_ISSET, et je traite si le resultat est positif.
Si j'arrive a une cellule contenant -1, je sais que j'ai atteint la fin du tableau.
Je n'ai plus qu'a intervertir les dernieres cellules du tableau avec les cases des sockets qui ont ete fermees, s'il y en a (3 ecritures d'entier en acces direct : -1 lors de la fermeture, copie du numero de la socket, puis -1 dans la derniere case).

[mercyril]

Plutot que select ou poll, il arrive un moment ou il faut envisager d'utiliser des choses specifiques a la plateforme (/dev/poll sous Solaris, epoll sous Linux, il me semble que certains BSD ont quelque chose de dimilaire) qui evite une recherche en O(N) pour trouver le fd sur quoi il y a de l'activite.

Exactement le genre de chose que je cherche, je vais jeter un oeil à epoll
C'est bien la recherche O(N) qui me gène le plus.

Une autre piste est de n'avoir qu'une thread qui fait le select mais passe les fd sur lesquels il faut agir aux autres threads, comme ca il y a moins de risque que toute l'activite se passe sur les fd d'une thread donnee en gardant les autres bloquees sur le select.

Effectivement, très intéressant, je me note ça dans un coin

[mercyril]

epoll : parfait dans mon cas, j'ai fait une petit implémentation pour voir hier et ca va le faire.