Cherche un avis éclairé sur les Threads

Le
William H. Boney
Bonjour,

Je suis autodidacte en Java et j'ai écrit une appli client/serveur de
chat.

Chaque client de ce chat est un thread qui passe son temps à dormir et
à checker toutes les 800 ms si quelque chose arrive dans son buffer.
Et lorsque le client est fermé, le Thread se termine de lui-même.

La question est la suivante: Si une centaine de personnes (ou plus)
utilise le chat simultanément, cela peut-il entrainer des problèmes de
"collision" entre les différentes priorités de chaque thread (dont je
laisse le soin de gérer à la JVM) ? Comment puis-je savoir à partir de
quel seuil mon "architecture" risque de devenir critique ?
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
jerome moliere
Le #623524
William H. Boney wrote:
Bonjour,

Je suis autodidacte en Java et j'ai écrit une appli client/serveur de
chat.

Chaque client de ce chat est un thread qui passe son temps à dormir et
à checker toutes les 800 ms si quelque chose arrive dans son buffer.
Et lorsque le client est fermé, le Thread se termine de lui-même.

La question est la suivante: Si une centaine de personnes (ou plus)
utilise le chat simultanément, cela peut-il entrainer des problèmes de
"collision" entre les différentes priorités de chaque thread (dont je
laisse le soin de gérer à la JVM) ?


juste une petite precision, ton application ne reclame pas un niveau de
priorite precis pour fonctionner ? si oui, c'est tres dangereux...
en gros ne jamais reposer sur un Thread.setPriority(level) pour une
application à base de threads car c'est s'exposer à d graves problemes
de protabilité... toujours utiliser des DP du type rendez vous ppour
gerer la synchronisation...

Comment puis-je savoir à partir de
quel seuil mon "architecture" risque de devenir critique ?


je presumme que ton application n'est pas concue pour que tousles
lcients soien tsur le même poste ? donc si cote serveur tu t'assures
bien de l'utilisation d'un pool de threads (et non pas
creation/destruction) à chaque socket..il n'y a guere de soucis de
montée en charge..c'est comme cela que fonctionnent tous les serveurs
TCP/IP (Apache 2.0 par exemple)....

ai je repondu a la question? :)
jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean13—82212111941

William H. Boney
Le #632178
Désolé pour la réponse tardive, j'étais à l'extérieur...

Côté synchronisation, je laisse la JVM gérer ça... Je déclare juste
certaines méthodes synchronized et c'est tout.

Pour le reste, ça se corse !

J'ai un pool d'une cinquantaine de Threads qui attendent. Une fois que
les protocoles sont établis, par contre, je crée un objet connexion
qui englobe la socket entrante et un nouveau thread qui va gérer le
traffic automatiquement sur cette socket. (Le thread qui a répondu
avant la création de l'objet retourne au pool).

Tous les objets connexion sont donc des connections directes et
persistantes qui sont stockées dans un vector. C'est là que je
commence à avoir peur !! Ça fonctionne très bien (j'ai fait des tests
avec une vingtaine de personnes en simultané), mais j'imagine qu'il y
a une limite au nombre d'objets persistants que je peux enmagasiner...
Comment l'estimer ?

Et bien que mes threads dorment la plupart du temps, ils doivent bien
consommer de la ressource. Comment apréhender cette ressource
consommée ?
jerome moliere
Le #632172
William H. Boney wrote:

Désolé pour la réponse tardive, j'étais à l'extérieur...

Côté synchronisation, je laisse la JVM gérer ça... Je déclare juste
certaines méthodes synchronized et c'est tout.

Pour le reste, ça se corse !

J'ai un pool d'une cinquantaine de Threads qui attendent. Une fois que
les protocoles sont établis, par contre, je crée un objet connexion
qui englobe la socket entrante et un nouveau thread qui va gérer le
traffic automatiquement sur cette socket. (Le thread qui a répondu
avant la création de l'objet retourne au pool).

Tous les objets connexion sont donc des connections directes et
persistantes qui sont stockées dans un vector. C'est là que je
commence à avoir peur !! Ça fonctionne très bien (j'ai fait des tests
avec une vingtaine de personnes en simultané), mais j'imagine qu'il y
a une limite au nombre d'objets persistants que je peux enmagasiner...
Comment l'estimer ?

c'est un peu dangereux car si une connexion se casse la gueule comment

tu fais ?
un heartbeat ou qqch du genre ?
la limitation quasi physique que je vois, puisque tes threads reprentent
(encapsulent) des connexions physiques (donc des sockets) c'est un truc
du genre le nombre maximal de descripteurs de fichiers geres par ta
machine!!!
là c'est dusysteme, man bash et ulimit sous Unix
sous windows jene sais pas.. :)
Et bien que mes threads dorment la plupart du temps, ils doivent bien
consommer de la ressource.


certes mais si c'est dans un pool ce poids est fixe !!!
Comment apréhender cette ressource
consommée ?


avec un profiler c'est fait pour cela...

www.java-channel.org chercher profiler!!!!
jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean13—82212111941

William H. Boney
Le #632169
c'est un peu dangereux car si une connexion se casse la gueule comment
tu fais ?


En fait, il y a un mécanisme qui gère les exceptions levées par les
connections fermées et qui élimine les objets en conséquence, en
terminant les threads concernés.
Ça me parait plutôt safe, non ?

Je te remercie en tout cas de tes pistes ! Je vais potasser tout ça...

Cordialement,

Publicité
Poster une réponse
Anonyme