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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
jerome moliere
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_ean1382212111941
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_ean1382212111941
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_ean1382212111941
William H. Boney
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 ?
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 ?
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
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_ean1382212111941
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_ean1382212111941
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_ean1382212111941
William H. Boney
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,
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...
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...
