[FRsAG] Visualisation graphique des crontabs
Bonjour, j'ai des centaines de crons, définie dans une 10ène de crontabs. Le tout géré par des développeurs... (c'est un autre débat). Je voudrais optimiser leur répartition dans le temps. Il y a des crons qui tournent toutes les minutes, les 3 minutes, à certaines heures, bref de tout. On se rend compte facilement qu'à chaque heure à la minute 0, on a plein de crons qui se lancent... et c'est aussi le cas à d'autres minutes. Est-ce que vous connaisseriez, ou auriez fait un outils qui permet d'avoir un affichage graphique du nombre de crons lancés par minutes, sur une journée ? Avec par exemple des couleurs qui tendent vers le foncé quand il y a beaucoup de crons qui se lancent dans la même minute... Un peu comme dans la "combined map" de visitors : http://www.hping.org/visitors/report.html Ainsi, je pourrais me rencontre facilement des minutes saturées, et déplacer ces crons à m+1 ou m+n... PS: Sur IRC on m'a orienté vers JobScheduler http://jeudisdulibre.be/wp-content/uploads/2010/11/jeudisdulibre-JobScheduler.pdf mais je n'ai pas envie ni le temps de migrer toutes ces crontabs vers cet outil ... -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Visualisation graphique des crontabs
Le 01/12/10, Greg a écrit : > Bonjour, > > j'ai des centaines de crons, définie dans une 10ène de crontabs. Le tout > géré par des développeurs... (c'est un autre débat). > Je voudrais optimiser leur répartition dans le temps. > Il y a des crons qui tournent toutes les minutes, les 3 minutes, à > certaines heures, bref de tout. > On se rend compte facilement qu'à chaque heure à la minute 0, on a plein > de crons qui se lancent... et c'est aussi le cas à d'autres minutes. > > Est-ce que vous connaisseriez, ou auriez fait un outils qui permet > d'avoir un affichage graphique du nombre de crons lancés par minutes, > sur une journée ? Avec par exemple des couleurs qui tendent vers le > foncé quand il y a beaucoup de crons qui se lancent dans la même > minute... Un peu comme dans la "combined map" de visitors : > http://www.hping.org/visitors/report.html > > Ainsi, je pourrais me rencontre facilement des minutes saturées, et > déplacer ces crons à m+1 ou m+n... > > PS: Sur IRC on m'a orienté vers JobScheduler > http://jeudisdulibre.be/wp-content/uploads/2010/11/jeudisdulibre-JobScheduler.pdf > mais je n'ai pas envie ni le temps de migrer toutes ces crontabs vers > cet outil ... > > -- > Greg > > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > C'est un beau problème de maths ça. :) T'as quelles contraintes sur l'outil? rendu HTML, console? Rémi. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Visualisation graphique des crontabs
Le 01/12/2010 15:14, Rémi Bouhl a écrit : C'est un beau problème de maths ça. :) T'as quelles contraintes sur l'outil? rendu HTML, console? Petite préférence pour console :) -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Fwd: PHPBB 2.x, soucis d'index
Salut :) Bien que je vous lise depuis un petit moment, c'est tout premier message parmi vous :) Je vous transmet un message que je viens de laisser sur les ML d'OVH. En espérant qu'il vous soit utile. Cordialement. -- Message transféré -- De : Utilisateur Salut :) Les débuts : Je m'occupe de deux sites assez fréquentés, tournant sous PHPBB 2.x. Au fur et à mesure que les sites grossissaient j'étais confronté à des problèmes de lenteur. Par manque d'expérience, je mettais ces soucis sur le serveur, je pensais qu'il n'était plus assez costaud (KS 1.2 Ghz, 1 Go de RAM). Avant de me lancer dans de coûteux investissements, j'ai décidé de chercher la cause de ces lenteurs. Pour voir si il serait possible de les amoindrir. Premier truc, j'ai stocké dans un tableau toutes les requêtes générées par PHPBB afin des les afficher en bas de pages. J'ai aussi ajouter un microtime() afin de savoir combien de temps a pris l'exécution de chaque requête. Une requête prenait 0.4 secondes pour s'exécuter (lors des heures de pointe, on pouvait monter à plus de 0.8 secondes). Voici la requête incriminée : [q] => SELECT t.forum_id, t.topic_id, p.post_time FROM phpbb_topics t, phpbb_posts p WHERE p.post_id = t.topic_last_post_id AND p.post_time > 1291203792 AND t.topic_moved_id = 0 [time] => 0.394723176956 C'est beaucoup ! Et cette requête est exécutée sur presque chaque page. Qu'est ce qui se passe ? Il n'y a tout simplement pas d'index sur "topic_last_post_id". J'ajoute un index, résultat : [q] => SELECT t.forum_id, t.topic_id, p.post_time FROM phpbb_topics t, phpbb_posts p WHERE p.post_id = t.topic_last_post_id AND p.post_time > 1291203792 AND t.topic_moved_id = 0 [time] => 0.00233793258 On est passés de 0.4 secondes à 0.002 secondes... Avec juste un index. Je laisse tourner quelques jours afin de voir ce que ça donne : Plus aucun ralentissement, les forums n'ont jamais été aussi rapides ! Les forums contiennent 700 000 messages, effectivement, un index manquant sur une table aussi sensible, ça joue beaucoup ! Je me demande, pourquoi ne pas avoir mis un simple index sur ce champ ? Ai-je fait une erreur lors d'une migration ? Lorsque j'ai appliqué un patch ? Je télécharge la dernière version publiée de PHPBB, la 2.0.23 et je regarde le fichier de création de la BDD. Aucun index n'est prévu par PHPBB : CREATE TABLE phpbb_topics ( topic_id mediumint(8) UNSIGNED NOT NULL auto_increment, forum_id smallint(8) UNSIGNED DEFAULT '0' NOT NULL, topic_title char(60) NOT NULL, topic_poster mediumint(8) DEFAULT '0' NOT NULL, topic_time int(11) DEFAULT '0' NOT NULL, topic_views mediumint(8) UNSIGNED DEFAULT '0' NOT NULL, topic_replies mediumint(8) UNSIGNED DEFAULT '0' NOT NULL, topic_status tinyint(3) DEFAULT '0' NOT NULL, topic_vote tinyint(1) DEFAULT '0' NOT NULL, topic_type tinyint(3) DEFAULT '0' NOT NULL, topic_first_post_id mediumint(8) UNSIGNED DEFAULT '0' NOT NULL, topic_last_post_id mediumint(8) UNSIGNED DEFAULT '0' NOT NULL, topic_moved_id mediumint(8) UNSIGNED DEFAULT '0' NOT NULL, PRIMARY KEY (topic_id), KEY forum_id (forum_id), KEY topic_moved_id (topic_moved_id), KEY topic_status (topic_status), KEY topic_type (topic_type) ); Comme je sais que beaucoup de forums sont restés sur PHPBB 2.x je me suis dit que ça pourrait vous intéresser. Passez une bonne journée :) A+ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Fwd: PHPBB 2.x, soucis d'index
Bonjour, Il faut je pense proposer ton patch à l'équipe de phpBB, pour inclusion dans le projet. Pour que le problème ne se reproduise plus dans les versions à venir ;) Cordialement, -Message d'origine- De : frsag-boun...@frsag.org [mailto:frsag-boun...@frsag.org] De la part de Utilisateur Envoyé : mercredi 1 décembre 2010 15:29 À : frsag@frsag.org Objet : [FRsAG] Fwd: PHPBB 2.x, soucis d'index Salut :) Bien que je vous lise depuis un petit moment, c'est tout premier message parmi vous :) Je vous transmet un message que je viens de laisser sur les ML d'OVH. En espérant qu'il vous soit utile. Cordialement. -- Message transféré -- De : Utilisateur Salut :) Les débuts : Je m'occupe de deux sites assez fréquentés, tournant sous PHPBB 2.x. Au fur et à mesure que les sites grossissaient j'étais confronté à des problèmes de lenteur. Par manque d'expérience, je mettais ces soucis sur le serveur, je pensais qu'il n'était plus assez costaud (KS 1.2 Ghz, 1 Go de RAM). Avant de me lancer dans de coûteux investissements, j'ai décidé de chercher la cause de ces lenteurs. Pour voir si il serait possible de les amoindrir. Premier truc, j'ai stocké dans un tableau toutes les requêtes générées par PHPBB afin des les afficher en bas de pages. J'ai aussi ajouter un microtime() afin de savoir combien de temps a pris l'exécution de chaque requête. Une requête prenait 0.4 secondes pour s'exécuter (lors des heures de pointe, on pouvait monter à plus de 0.8 secondes). Voici la requête incriminée : [q] => SELECT t.forum_id, t.topic_id, p.post_time FROM phpbb_topics t, phpbb_posts p WHERE p.post_id = t.topic_last_post_id AND p.post_time > 1291203792 AND t.topic_moved_id = 0 [time] => 0.394723176956 C'est beaucoup ! Et cette requête est exécutée sur presque chaque page. Qu'est ce qui se passe ? Il n'y a tout simplement pas d'index sur "topic_last_post_id". J'ajoute un index, résultat : [q] => SELECT t.forum_id, t.topic_id, p.post_time FROM phpbb_topics t, phpbb_posts p WHERE p.post_id = t.topic_last_post_id AND p.post_time > 1291203792 AND t.topic_moved_id = 0 [time] => 0.00233793258 On est passés de 0.4 secondes à 0.002 secondes... Avec juste un index. Je laisse tourner quelques jours afin de voir ce que ça donne : Plus aucun ralentissement, les forums n'ont jamais été aussi rapides ! Les forums contiennent 700 000 messages, effectivement, un index manquant sur une table aussi sensible, ça joue beaucoup ! Je me demande, pourquoi ne pas avoir mis un simple index sur ce champ ? Ai-je fait une erreur lors d'une migration ? Lorsque j'ai appliqué un patch ? Je télécharge la dernière version publiée de PHPBB, la 2.0.23 et je regarde le fichier de création de la BDD. Aucun index n'est prévu par PHPBB : CREATE TABLE phpbb_topics ( topic_id mediumint(8) UNSIGNED NOT NULL auto_increment, forum_id smallint(8) UNSIGNED DEFAULT '0' NOT NULL, topic_title char(60) NOT NULL, topic_poster mediumint(8) DEFAULT '0' NOT NULL, topic_time int(11) DEFAULT '0' NOT NULL, topic_views mediumint(8) UNSIGNED DEFAULT '0' NOT NULL, topic_replies mediumint(8) UNSIGNED DEFAULT '0' NOT NULL, topic_status tinyint(3) DEFAULT '0' NOT NULL, topic_vote tinyint(1) DEFAULT '0' NOT NULL, topic_type tinyint(3) DEFAULT '0' NOT NULL, topic_first_post_id mediumint(8) UNSIGNED DEFAULT '0' NOT NULL, topic_last_post_id mediumint(8) UNSIGNED DEFAULT '0' NOT NULL, topic_moved_id mediumint(8) UNSIGNED DEFAULT '0' NOT NULL, PRIMARY KEY (topic_id), KEY forum_id (forum_id), KEY topic_moved_id (topic_moved_id), KEY topic_status (topic_status), KEY topic_type (topic_type) ); Comme je sais que beaucoup de forums sont restés sur PHPBB 2.x je me suis dit que ça pourrait vous intéresser. Passez une bonne journée :) A+ ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Fwd: PHPBB 2.x, soucis d'index
Je vais voir pour faire ça, mais je ne sais pas si ça va servir à grand chose. Il me semble que la branche 2.x n'est plus supportée depuis un bon moment. ___ Liste de diffusion du FRsAG http://www.frsag.org/
