Trop de threads ?

Bonjour,

J'aimerais développer une application qui serait comme une école virtuelle. C'est à dire que les élèves et les profs se connectent et rentrent dans l'école. Ils voient la liste des classes et peuvent rentrer dans une d'elles. Une fois dans une classe, ils peuvent chater (comme sur IRC par exemple), parler (tout le monde entend tout le monde), voir le prof par sa webcam ou encore tous dessiner au tableau.

Tout ceci sera centralisé sur un serveur dédié.
On va imaginer que le logiciel plait à beaucoup de monde, il y a donc 200 classes et 2000 personnes connectées.
Je pense utiliser des QTcpSocket et un QtcpServer pour faire tout ça.

Quelle architecture choisir pour que le serveur soit efficace ?

Je pense que le plus simple pour éviter les blocages est d'utiliser des qthread partout : chaque client a sa socket sur un thread côté serveur, chaque classe a son thread, chaque chat audio aussi... Chaque thread est peu utilisé et passe le plus clair de son temps en attente donc je ne pense pas que l'utilisation CPU soit le problème (si ?). Le problème que je vois est l'utilisation mémoire : si chaque thread a une pile de 8Mo et qu'il y a 3000 threads ça va reserver 24Go.

Vaut-il mieux utiliser un autre procéder pour gérer la concurrence ? Avoir une serveur dédié avec directement 48Go de RAM ? Réduire la taille de la pile d'un thread ?

Merci d'avance si vous avez des idées.

Bonsoir,

Tu devrais regarder du côté de la classe QThreadPool.

:fleche: Lien vers la documentation officielle (en anglais): QThreadPool

Tschüß!

:salut:

Un thread par connexion n'est pas toujours la meilleure idée. Exemple pratique : Apache httpd et nginx (voir http://www.wikivs.com/wiki/Apache_vs_nginx et les différents benchmarks). La différence entre les deux est leur architecture : httpd fonctionne avec des thread et des forks de processus, ngingx avec des événements.

Bonjour,

Merci pour ces réponses ! j'ai pu découvrir les QRunnable et que "ngnix" n'était pas une onomatopée pour dire qu'il y avait un problème :oops:.
Je vois à peu près comment QThreadPool fonctionne donc je considère la solution.
Pour une gestion par évènements, j'utiliserais donc une seule socket qui écouterait tous les clients et dès que je reçoit un paquet, j'envoie un signal, non ?
Seulement, je pensais utiliser un port de connexion qui ne lit jamais les données mais quand une connexion est demandée, il envoie le numéro d'un nouveau port qui est celui d'un QSslSocket sur le serveur et qui n'écoute que ce client.
Le client se déconnecte du port de connexion et se connecte en crypté au nouveau port, lui envoie le pseudo et le mot de passe. Côté serveur, la socket lit un nombre limité de char, si les identifiants correspondent, il connecte le client à une nouvelle socket non crypté qui n'écoute que ce client, sinon, il met une pénalité de quelques secondes avant de se remettre à lire.
Ceci a pour but d'éviter que quelqu'un flood le serveur et de gérer la connexion sécurisée. Si il y a d'autres méthodes ou que celle ci n'est pas bonne, n'hésitez pas !
Le problème avec une seule socket (une fois connectée), c'est que je ne peux pas dire à une socket d'écouter n adresses ou de lui dire d'écouter une adresse en plus, si ?
L'autre soucis et que je ne sais pas comment faire pour savoir de quel client vient tel paquet et si après un read(), j'ai mon paquet entier, enfin bref, j'ai peur que tous les clients se marchent sur les pieds.

Est-ce que Qt va encore me surprendre par sa simplicité ou s'agit-il d'un vrai problème ?

1thread par connexion avec 2000 personne connectées == 2000 threads
...!!!! 8O

Les classe de QtNetwork sont asynchrone. Donc pas besoin de créer autant de thread. Tu devrais pourvoir facilement regrouper plusieurs connexion sur un même thread.
As tu des notions de signal/slots? As tu regardé les examples de Qt?


Pour info, le nombre de thread est limité : http://blogs.technet.com/b/markrussi...8/3261309.aspx

Bonjour,

Merci, effectivement, je faisais sûrement un amalgame entre une socket et un thread. Ca ne poserait donc pas de problème de mettre 2000 sockets dans le même thread et de connecter 2000 fois readyRead() ? Si la réponse est oui, le sujet est résolu car ce qui me posait vraiment problème était de n'avoir qu'une socket.
Oui, j'avais déjà vu qu'il y avait une limite mais (sous linux au moins) il est possible de la modifier.

Citation:

---

Envoyé par autre mickael

Bonjour,

Merci, effectivement, je faisais sûrement un amalgame entre une socket et un thread. Ca ne poserait donc pas de problème de mettre 2000 sockets dans le même thread et de connecter 2000 fois readyRead() ? Si la réponse est oui, le sujet est résolu car ce qui me posait vraiment problème était de n'avoir qu'une socket.
Oui, j'avais déjà vu qu'il y avait une limite mais (sous linux au moins) il est possible de la modifier.

---

Si les traitement sont très simple, ca peut suffire. Perso, j'aurais créé autant de thread que de coeur et équilibré le nombre sockets sur chacun de ces threads.

Il faut bien comprendre comment fonctionne les signal/slot(et donc le fonctionnement asynchrone) de Qt et à quoi sert movetothread. Regarde la FAQ ;)

Merci !
Oui, utiliser tous les coeurs va être plus efficace.
Après je ne suis pas sûr de devoir utiliser moveToThread car connect() par défaut, effectue le traitement dans le thread receveur et ce lien contre-indique l'utilisation de cette méthode. Je pense que pour les classes (au sens salle de cours, cf mon premier post), je vais essayer d'utiliser le même mécanisme.
Merci à tous !

Citation:

---

Envoyé par autre mickael

Après je ne suis pas sûr de devoir utiliser moveToThread car connect() par défaut, effectue le traitement dans le thread receveur et ce lien contre-indique l'utilisation de cette méthode.

---

Il ne le contreindique pas explique ce qu'il ne faut pas faire avec ;)

Mais dans un premier temps ce n'est pas le plus important. Peut être plus tard