Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 9 sur 9
  1. #1
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2011
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2011
    Messages : 13
    Points : 17
    Points
    17

    Par défaut Server multi client conception

    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 ?

  2. #2
    Modérateur
    Avatar de gangsoleil
    Profil pro
    R&D en systemes informatiques bas niveau Unix/Linux
    Inscrit en
    mai 2004
    Messages
    8 411
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : R&D en systemes informatiques bas niveau Unix/Linux

    Informations forums :
    Inscription : mai 2004
    Messages : 8 411
    Points : 21 221
    Points
    21 221

    Par défaut

    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.
    Modérateur "C", "Informatique Générale & Hardware" et "Unix"
    Les règles du forum

  3. #3
    Membre habitué
    Homme Profil pro Allan
    Étudiant
    Inscrit en
    août 2012
    Messages
    82
    Détails du profil
    Informations personnelles :
    Nom : Homme Allan
    Âge : 24
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : août 2012
    Messages : 82
    Points : 119
    Points
    119

    Par défaut

    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.

  4. #4
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2011
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2011
    Messages : 13
    Points : 17
    Points
    17

    Par défaut

    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

  5. #5
    Modérateur
    Avatar de gangsoleil
    Profil pro
    R&D en systemes informatiques bas niveau Unix/Linux
    Inscrit en
    mai 2004
    Messages
    8 411
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : R&D en systemes informatiques bas niveau Unix/Linux

    Informations forums :
    Inscription : mai 2004
    Messages : 8 411
    Points : 21 221
    Points
    21 221

    Par défaut

    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).
    Modérateur "C", "Informatique Générale & Hardware" et "Unix"
    Les règles du forum

  6. #6
    Expert Confirmé Sénior

    Inscrit en
    novembre 2005
    Messages
    5 104
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 104
    Points : 5 985
    Points
    5 985

    Par défaut

    Citation Envoyé par gangsoleil Voir le message
    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.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  7. #7
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2011
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2011
    Messages : 13
    Points : 17
    Points
    17

    Par défaut

    Citation Envoyé par gangsoleil Voir le message
    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).

  8. #8
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2011
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2011
    Messages : 13
    Points : 17
    Points
    17

    Par défaut

    Citation Envoyé par Jean-Marc.Bourguet Voir le message
    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.

    Citation Envoyé par Jean-Marc.Bourguet Voir le message
    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


  9. #9
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2011
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2011
    Messages : 13
    Points : 17
    Points
    17

    Par défaut

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

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •