Discussion :

[Gregory666]

Bonsoir ,

Avec IdTcpclient et idTcpserver dans la même application y a-t-il un risque de bug, style blocage de l'application ou lenteur , en sachant qu'un Thread est lancé pour la réception des messages clients ?

Je voudrais mettre la partie serveur dans un "DataModule".

Ça m'embête un peu de faire 2 applications

Merci pour votre réponse

[Gregory666]

Tout conte fait c'est pas plus mal qui reste en externe , j'ai fait une simulation avec 30 clients connectés ou j'ai intégré un timer a chaque clients qui envoi un message privée chaque secondes a un client aléatoire connecté sur le serveur, le résultat c'est que mon CPU est monté a 100% mon processeur et un AMD fx-9370 (4.4 ghz) 8 cœurs , 8 GO de RAM , j'ai laissé la simulation une bonne heure , aucun plantage côté client que côté serveur sa fait pas mal d’échange 30 clients qui envoi un message tout les secondes au serveur qui lui doigt renvoie se message au destinataire sa fait 30 x 30 = 900 messages secondes.

Les messages envoyer été aléatoire sur une longueur de chaire a 255 caractères.

[Gregory666]

Je serai bien curieux de savoir sur quoi son installé les serveurs de différent IRC sur le net , je pence pas que c'est juste un PC (Standard) qui gère le serveur car cela demande énormément de ressource.

[ShaiLeTroll]

Je note que tu as fait des tests très similaires aux miens

il y a de forte chance que cela ne soit pas un Windows mais plutôt un Linux, lorsque j'ai travaillé avec du PHP, l'hébergeur fonctionnait en Ubuntu et un autre sur Fedora
De plus, ce sont des fermes qui fusionne plusieurs lames, en fait cela peut être un tas de CPU genre 64 ou plus, qui partage des disques, ensuite le fournisseur te propose des machines virtuelles ayant un nombre défini de CPU
C'est des architectures bien plus poussés qu'un PC de bureau

En Windows 2000, cela plafonnait à 2000 TCP Control Block (TCB), c'était modifiable en base de registre.
il fallait bien trouver des astuces pour que cela puisse dépasser avec des performances correctes cela en répartissant les connexions à plusieurs serveurs
Aujourd'hui, un PC de bureau à les performances d'un monstre des années 2000

C'est le principe du répartiteur de charge, tu te connectes sur un frontal (ou plusieurs, oui, tu peux avoir un répartiteur de charge sur les frontaux eux-même) qui ne servent que de point d'entrée,
ces frontaux ont une ferme de serveur et en choisisse un et l'attribue au nouveau client connecté
Un échange de 2007 sur un sujet similaire : Delphi 5 et threads en nombre

De plus côté serveur, au lieu de créer un thread de lecture de connexion,
le serveur va attribué plusieurs de connexions à un même thread dans une pool de thread

Avec les anciens Delphi, dépasser 32 threads étaient contre-performants, avec FastMM ou les Delphi XE plus ce soucis

[Gregory666]

Fin il faut dire que le teste est extrême quand même , si sa c'est pas du flood , je faire bien un teste sous Linux avec le serveur, pour voir se que sa donne, je suis sur Embarcadero RAD Studio 2010 je dispose aussi d'un XE4 , mais galère avec les différente bibliothèques 32 & 64 ... pour installer les composants je passe 1 heures a configuré le XE4 , je me suis même dit que un jour , je réinstaller Windows 7 puis Xe4 + la configuration est je grave tout sur un blu ray.

On gros pour monté un serveur de chat privée cher sois avec ~ 50 - 100 clients un faut un "Cyber Calculator" Ou invertir dans un carte mère double CPU "ASUS Z10PE-D16 WS" Monter sur 2 "I7"
pour une charge de 80 clients , il faut une bécane bien huiler.

[ShaiLeTroll]

il faut une bécane bien huiler.

Il faut surtout une machine stable, tu n'as pas besoin d'un monstre, un Chat, cela ne consomme rien,
cela ne fait que transmettre du texte d'un client à un autre, côté serveur, il n'y a pas de ressource énorme,
une mini base embarquée pour gérer les comptes utilisateurs (tout peut se faire via un format de fichier maison)

Ton test extrême doit simuler 10 fois plus de charge que la réalité !

Tu évoques 50/100 utilisateurs, ce n'est rien comme charge, comme je mentionnais, tu peux monter à 2000 simultanés sur une vieille bécane de l'époque de Win2K
Avec n'importe quel PC, tu peux faire tourner ton serveur de Chat qui n'a pas grand chose à faire qu'a router les trames vers ses clients.
Il n'a quasiment calcul à effectuer, bien moins gourmand qu'un serveur Web devant générer de l'HTML/XML/JS/JSON ...

Lorsque j'évoquais du répartiteur de charge, c'est plus pour des Servers Web dont le temps de calcul de la requête est plus long
Pour un chat, sur un serveur linux, on irait sur ce genre de mécanisme lorsque l'on dépasse la dizaine de milliers d'utilisateurs en même temps, 50 c'est de la rigolade !
Et pour les serveurs IRC, en général, il n'y a pas de répartiteur, c'est souvent une liste de nom de serveur, lorsque tu choisis un réseau de serveur, tu en testes un, si il répond pas, tu en testes un autre ...
le répartiteur c'est l'utilisateur qui cherche un serveur disponible manuellement

Si tu veux regarder autour de Linux, prend tout simplement l'un des nombreux serveurs Open Source !
Si c'est juste pour avoir ton serveur, ne te fatigue pas !
Si c'est pour le fun d'en coder un, ça c'est tout autre chose !

[Gregory666]

Bonjour ShaiLeTroll

tu n'as pas besoin d'un monstre, un Chat, cela ne consomme rien

Je n’arrive pas a comprendre pourquoi le IdTCPServer consomme énormément de ressource , je viens de faire un test sur un pc standard ou j'ai mi le serveur , j'ai connecté 7 clients le CPU du PC été déjà monté a 100% , j'ai connecté un autre clients qui lui a fait planter le serveur (C'est la goutte qui a fait débordé le vase).

J'ai remonter mon Timer a 2 messages secondes , en pansent que sa prouvé réduire la charge du serveur.

[Gregory666]

10 Clients connectés , pas d’échange entre clients , CPU 100% pour 13 Threads



A Côté de sa Firefox tour actuellement avec 63 Threads , CPU 2%, Plus il y a de Thread moin tu consomme

[Gregory666]

Je pence avoir résolut le problème avec "Connection.IOHandler.CheckForDataOnSource(5);" , j'ai monté 32 clients CPU 1%

[Paul TOTH]

Bonjour ShaiLeTroll



Je n’arrive pas a comprendre pourquoi le IdTCPServer consomme énormément de ressource , je viens de faire un test sur un pc standard ou j'ai mi le serveur , j'ai connecté 7 clients le CPU du PC été déjà monté a 100% , j'ai connecté un autre clients qui lui a fait planter le serveur (C'est la goutte qui a fait débordé le vase).

J'ai remonter mon Timer a 2 messages secondes , en pansent que sa prouvé réduire la charge du serveur.

sans code il va être difficile de le deviner.

[ShaiLeTroll]

Je pence avoir résolut le problème avec "Connection.IOHandler.CheckForDataOnSource(5);" , j'ai monté 32 clients CPU 1%

Je dois avoir un timeout de message de 60000 ms, pour être sur que la connexion toujours établi, cela envoie un Keep Alive Maison si pas d'échange dans la minute
En fait, les threads passent leur temps à attendre via WaitForData, cela fonctionne comme un TEvent, cela attend que le signal soit levé !

Pour le IdTCPServer, je n'ai pas aimé son utilisation, je suis resté fidèle au TServerSocket encpasulé dans mon TSLTRemoteMessenger

[Gregory666]

Déterminé le délai d'attente ?

Si le délai d'attente est 1 seconde sa veut dire que le serveur va remplir la mémoire tampon d'entrée, puis si les 1 seconde son écoule il va exécute l'action.

J'ai du mal a comprendre le "CheckForDataOnSource" j'ai rechercher dans les Docs Indy 10 mais j'ai rien trouvé a se sujet.

[ShaiLeTroll]

Si le délai d'attente est 1 seconde sa veut dire que le serveur va remplir la mémoire tampon d'entrée, puis si les 1 seconde son écoule il va exécute l'action.

Non, c'est le délai maximum d'attente, en tout cas pour le WaitForData
Si il a des données, il rend la main tout de suite
Il te suffit d'avoir le moindre petit octet pour qu'il rend la main
En général, il accumule au plus 8Ko si tu as beaucoup de donnée d'un coup, il faut boucler pour récupérer les paquets suivants.
Si tu as moins de 8Ko, tu as tout d'un coup.

Si il n'a pas de données, il attend au plus le délai pour rendre la main
C'est à ce moment, que je fais mon KeepAlive maison

Attend jusqu'à TimeOut millisecondes que la connexion de socket soit prête à transférer des données.

Appelez WaitForData pour garantir que la connexion de socket soit prête à lire et à écrire des informations. WaitForData renvoie true si la connexion de socket est prête. WaitForData renvoie false si la connexion de socket n'est toujours pas prête au bout de TimeOut millisecondes.

Appelez WaitForData avant de lire ou d'écrire des informations via la connexion de socket. Sinon, les méthodes Read ou Write peuvent dépasser le délai limite avant de n'avoir rien transféré.

Pour le TIdIOHandler.CheckForDataOnSource
Indy avec ses abstractions, ce n'est pas évident à comprendre, mais je pense que le TIdServerIOHandler fonctionne de la même façon, il attend que des données soient disponibles, dès qu'il y en a il les retourne, et si le délai est dépassé, il rend la main
tu sais qu'il y a des données en utilisant ...IOHandler.InputBuffer.ExtractToBytes(TIdBytes)