Bonjour,
 
J'utilise les librairies Thread et Asio de Boost (donc en C++) pour faire un aspirateur de pages web (c'est pour un projet)
Mon but est donc de traiter le plus de pages en même temps. Chaque thread lancé se connecte au serveur pour récupérer une page et la traiter.
Seulement on me demande d'optimiser la gestion des threads, c'est-à-dire d'en lancer jusqu'à ce que le serveur commence à s'effondrer.
 
C'est cette dernière chose qui me pose problème : comment repérer le début de l'effondrement d'un serveur ?
Il me semble que les serveurs ont un nombre limité de connexions simultanées, mais que celui-ci varie en fonction de la configuration du serveur.
 
Pour info j'ai tenté de lancer 250 threads sur un même serveur (celui de mon école), et en 7 secondes 210 threads (en moyenne) me ramènent le contenu de la page visée, et les autres je ne sais pas ce qu'ils deviennent, car apparament aucune exception n'est lancée.
 
Avez-vous des infos qui pourraient m'aider svp ?
Merci

Je pense que tu peux regarder le délai moyen de réponse d'un thread, et s'il commence à augmenter de manière significative (et là est tout le problème, il te faudra définir ce que "significatif" signifie), tu arrêtes.
Ceci dit je trouve que c'est un peu risqué comme pratique... Il est en effet relativement simple de configurer iptables (ou autre firewall) pour qu'il détecte ce genre de comportement ( = même IP envoyant un grand nombre de requêtes en peu de temps) et d'appliquer une règle de QoS restrictive ou la blacklister ... Généralement on essaie de faire en sorte que les aspirateurs agissent d'une manière proche de celle d'un humain ( => pas 100 requêtes / sec) afin de ne pas être blacklistés

Tu définis une période de temps (genre 1/10 de sec, au pif). Tu mesure pour chaque période le débit total de tout tes threads. Ensuite à chaque fin d'intervale tu prends une décision, soit tu augmente le nombre de threads, soit tu le réduis :
- si le débit est plus gros que la période précédente on reprends la même décision qu'on a prise à a période précédente.
- si le débit est plus faible, on prends la décision inverse.
 
C'est pas parfait, mais ça peut faire un bon départ, le seul cas ou ça peut problème c'est sur le fait que quand t'as trouvé la bonne valeur le truc oscille, si c'est entre 250 et 251 threads tu t'en fout, si c'est entre 2 et 3 parceque le serveur limite en dur par contre l'oscillation sera trop violente et pas efficace (dans ce cas on peut imaginer un mécanisme d'ammortissement assez simple).