Discussion :

[sleeg]

Bonjour,

Je voudrais créer un programme qui lit des flux de données (très léger), et enregistre les infos dans la base de donnée...

Actuellement, je fait lire 20 flux en même temps avec une répétition toute les 10sec... Si je met la répétition à 1 sec, toutes les données n'ont pas le temps d'être enregistrées... Mon but serait de pouvoir lire environs 200 flux à la fois avec moins d'une seconde de répétition.

Quelqu'un a une solution? Faudrait-il créer une sorte de file d'attente pour faire tous les traitements(lire le flux, le désérialiser et enregistrer les données) ? L'utilisation des Thread est-elle la solution? si oui, comment les utiliser dans ce cas?

Merci pour vos réponses et vos tuyaux.

[DonQuiche]

Bonjour.

Tout ça est un peu vague. Oublions ces "X flux, Y secondes" qui ne nous apportent rien. Si j'ai bien compris le goulot d'étranglement est l'enregistrement dans la base de données (à vérifier en mettant en commentaire les enregistrements). Dans ce cas les bonnes questions sont :
* Le problème est-il dû à des accès disques trop lents ou à des requêtes ou une structure trop lourdes (indices inutiles à mettre à jour par ex) ? Combien d'entrées insérées, supprimées ou modifiées par seconde ? Quel volume de données (Mo/s) ? Combien de tables affectées ?
* La base de données est-elle une finalité nécessaire ou était-ce un choix de design ?
* Quel SGBD ? La base pourrait-elle tenir en mémoire ?


Si c'est la DB le problème (il faut s'en assurer), inutile de paralléliser le code, ça ne donnera qu'un gain marginal malgré beaucoup d'efforts et de risques. Par ailleurs si la DB est monopolisée en permanence, une file d'attente n'améliorerait pas davantage les choses. Si la DB est bien le problème et que ce n'est pas le fait d'accès disques trop importants, alors la structure est peut-être mal fichue ou les requêtes inefficaces.


Enfin une remarque importante : toute optimisation passe par l'obtention de mesures. Il faut savoir ce qui cause les ralentissements et comprendre pourquoi. Une fois que c'est fait la réponse à donner est presque évidente. Il existe des outils de profilage du code, les SGBD fournissent leur propres outils de profilage pour leurs opérations, et enfin il faut distinguer la part du temps occupée par les entrées/sorties (matériel) de celle occupée par les traitements (logiciel : application + SGBD).

La bonne question n'est pas : "comment faire pour que ça aille plus vite ?" mais "pourquoi ça rame ?"

[Kikuts]

DonQuiche résume bien les choses

Il ne faut pas traiter le problème mais la cause/source !

Cela ne servirait à rien de passer 1 mois à optimiser tes traitements avec du traitement parallèle et gagner 10% de flux traités en plus si en passant 2 semaines à optimiser tes requêtes SQL tu gagnes 30% de perf.

C'est pour cela qu'il faut que tu cernes avant de te lancer dans de l'optimisation, les différentes causes de ces lenteurs.

Tu peux schématiser le workflow de ton traitement et noter combien de temps prends chaque étapes et faire une liste des optimisations possibles pour chaque process du processus complet.