+- Communauté Eggdrop (https://forum.eggdrop.fr)
+-- Forum : Eggdrop et TCL (https://forum.eggdrop.fr/forumdisplay.php?fid=8)
+--- Forum : Scripts TCL (https://forum.eggdrop.fr/forumdisplay.php?fid=4)
+--- Sujet : MySQL-TCL (/showthread.php?tid=317)
Pages :
1
2
MySQL-TCL - BeussAy - 09/01/2009
Coucou.
En faite je n'ai pas de problème mais plus besoin de vos avis.
Je m'explique:
Je suis sur un petit projet concernant un tcl qui gère toutes ses données via SGBD (MySQL).
Ce tcl est du style d'Anope il gère donc NickServ, ChanServ, BotServ ect .. via MySQL et boot à partir de celle-ci.
Pensez que la BDD va être secouée avec toutes les requêtes qu'elle va subir?
En sachant que le site travaillera sur les même BDD.
En gros j'ai peur de saturé mes BDD.
J'avais commencé à d'abord stocker les données dans un fichier et avec un bind - time vérifier toutes les 5 minutes les changements éffectués.
Qu'est ce que vous en pensez?
Merci d'avance
Crdlt BeussAy
RE: MySQL-TCL - Merwin - 09/01/2009
Non mais une BDD ça sature pas, t'en fais pas.
A moin que t'avoisines les 5000req/s ce qui est loin d'être le cas.
Si tu a peur établies une connexion persistante au serveur ça t'économisera le temps d'ouverture des sockets.
Une requete SQL bien pensée, ça prend 1-20ms même pas.. don t'en fais pas, surtout en local.
RE: MySQL-TCL - BeussAy - 09/01/2009
Oui en me baladant sur divers forum j'ai vu plusieurs informations intéressantes.
A partir du moment que les requêtes ne sont pas longues et/ou qu'elles sont ouvertes le plus tard et fermées le plus tôt possible pas de soucis.
Thx
RE: MySQL-TCL - CrazyCat - 09/01/2009
Heu, une requète SQL peut prendre beaucoup de temps (plus de 5s), il faut que les tables soient optimisées.
Mais c'est rarement MySQL qui fait défaut, plutôt le programmeur. J'ai vu des requêtes diminuer de moitié leur temps juste avec un index bien placé, et même un serveur bien mieux répondre à une grosse requète qu'une multitude de petites.
RE: MySQL-TCL - BeussAy - 10/01/2009
Donc le faite d'effectuer des vérifications toutes les x secondes dans mes fichiers pour ensuite faire les modifications nécéssaire me semble bien.
J'ai vu dans plusieurs forum ce que tu viens de dire.
Il est préférable d'effectuer une grosse requête bien pensée que plusieurs petite. Ça évite les I/O.
Crdlt
RE: MySQL-TCL - Merwin - 10/01/2009
En effet, utilises plutot des INNER JOIN, et autres pour éviter de faire plusieurs requetes.
Je ne sais pas comment sont les tables d'Anope, mais si elles sont bien pensée en 1 requete tu peux récupérer n'importe quelle info.
Si tu fais plutot des UPDATE, penses à vérifier si Anope utilise des Foreign key. De plus, je ne crois pas que MySQL supporte la vérification du bon aboutissement des requetes, (En gros: tu fais X requetes UPDATE, il ne les prendra en compte que si TOUTES aboutissent correctement ,si une échoue, aucune n'est prise en compte). Je sais que PostgreSQL le supporte en tout cas.
RE: MySQL-TCL - CrazyCat - 10/01/2009
Au cas où, je veux bien filer un petit coup de main pour la structure des tables et les requètes.
Concernant les tables d'anope, j'avais commencé à faire un petit reverse-engineering dessus, ça pourrait être intéressant que je le diffuse. Mais les tables sont assez basiques, et comme MySQL gère assez mal les FK, elles ne sont pas explicités.
RE: MySQL-TCL - BeussAy - 10/01/2009
Ha j'ai oublié de préciser que j'utilise des tables différentes de celle d'anope, en faite je refait un "style" d'anope en tcl, pour mon utilisation en gros une gestion web/irc avec interface de gestion pour les owner ect ...
Les tables utilisées sont les notre.
Je me suis aussi créé quelques procs pour pouvoir récupérer/ajouter/del plusieurs infos dans mes tables pour éviter un trop grand nombre de petites connexions.
En gros les requêtes qui risquent d'être le plus souvent sollicitée genre (informations salons ect ..) sont d'abord gérées via db et ensuite la vérification est faites toutes les 5 minutes pour vérifier les modifications (dans les 2 sens db -> SQL & SQL -> db).
j'avais peur de revoir refaire pas mal de truc mais je suis partis du bon pied.
Merci de vos avis.
RE: MySQL-TCL - CrazyCat - 10/01/2009
Jette un coup d'oeil sur Denora si tu veux t'inspirer
RE: MySQL-TCL - BeussAy - 10/01/2009
Ouep j'ai fouillé un peu partout (une vraie fouine :p)
Je vous inviterai à venir tester ça des que ça sera en place.
On à pas mal de taf surtout niveau site.
Vous nous donnerez vos avis si ça vous dis.
Merci de ceux-là déjà.
Edit: Je vous joint quand même mes structures. Histoire de voir si je peux optimiser ça. Merci
Crdlt
RE: MySQL-TCL - Merwin - 10/01/2009
J'ai pas matté les structures, mais je vois pas l'intéret de faire un fichier db temporaire.
Ca prend autant de temps que de faire directement ta requete, car au final sur un MySQL local, ça revient à ouvrir un socket local, donc un fifo...
RE: MySQL-TCL - BeussAy - 10/01/2009
- Déjà ça m'évite de faire une requête à chaque action comme topic, modes ect ..
- Ensuite si un changement est effectué sur la BDD je le repère plus facilement ceux-ci pour effectuer le changement sur IRC
Crdlt
RE: MySQL-TCL - CrazyCat - 10/01/2009
Je pense sincèrement qu'il vaut mieux effectuer directement une action sur la base (en REPLACE plutôt qu'en UPDATE) et ne pas se poser de questions sur la charge du serveur SQL, à moins que ton réseau ne compte quelques milliers d'utilisateurs.
RE: MySQL-TCL - BeussAy - 10/01/2009
Je comprends, lorsqu'une commande est effectuée sur IRC c'est le cas.
Mais si un owner modifie une option de son interface via le site, ça ce corse.
RE: MySQL-TCL - CrazyCat - 11/01/2009
Ah oui, dans ce sens... un script PHP qui ferait du fsockopen vers ton serveur pour appliquer les nouveaux paramètres?