- Messages : 167
Restauration de la base trop longue
- scoubinaire
- Auteur du sujet
- Membre elite
Moins
Plus d'informations
il y a 4 ans 6 mois #2642
par scoubinaire
Restauration de la base trop longue a été créé par scoubinaire
Bonjour Yann
Je pense qu'il faudrait améliorer GRR car les restaurations de la base GRR sont trop longues
Ma base de données GRR contient 18000 rangées
- avec une sauvegarde et restauration par GRR, temps estimé 17 minutes (Fatal error: Maximum execution time of 240 seconds exceeded in \xampp744\htdocs\grr341c\include\mysql.inc.php on line 74)
- avec un Export puis Import avec phpmyadmin : 70 secondes soit 15 fois plus rapide !
La raison c'est que dans admin_save_mysql.php une commande INSERT INTO est générée par chaque rangée dans les tables par :
$sInsert = "INSERT INTO $temp $sFieldnames values ";
mais dans phpmyadmin, il y a un INSERt INTO pour 200 à 300 rangées, (c'est variable)
Il y a aussi des petits programmes sur Internet qui ne génère les INSERT INTO que toutes les 100 rangées, comme dans
stackoverflow.com/questions/40885525/mul...from-mysql-using-php
ce qui permet aussi de faire des imports beaucoup plus rapide (plus de 10 fois plus rapides)
Exemples :
- Export GRR
INSERT INTO grr_entry values (38207, 1453728600, 1453735800, ...
INSERT INTO grr_entry values (38208, 1456147800, 1456155000, ...
INSERT INTO grr_entry values (38209, 1459168200, 1459175400, ...
- Export phpmyadmin
INSERT INTO `grr_entry` (`id`, `start_time`, ...) VALUES
(38207, 1453728600, 1453735800, ...
(38208, 1456147800, 1456155000, ...
(38209, 1459168200, 1459175400, ...
Cordialement Jean-Pierre
Je pense qu'il faudrait améliorer GRR car les restaurations de la base GRR sont trop longues
Ma base de données GRR contient 18000 rangées
- avec une sauvegarde et restauration par GRR, temps estimé 17 minutes (Fatal error: Maximum execution time of 240 seconds exceeded in \xampp744\htdocs\grr341c\include\mysql.inc.php on line 74)
- avec un Export puis Import avec phpmyadmin : 70 secondes soit 15 fois plus rapide !
La raison c'est que dans admin_save_mysql.php une commande INSERT INTO est générée par chaque rangée dans les tables par :
$sInsert = "INSERT INTO $temp $sFieldnames values ";
mais dans phpmyadmin, il y a un INSERt INTO pour 200 à 300 rangées, (c'est variable)
Il y a aussi des petits programmes sur Internet qui ne génère les INSERT INTO que toutes les 100 rangées, comme dans
stackoverflow.com/questions/40885525/mul...from-mysql-using-php
ce qui permet aussi de faire des imports beaucoup plus rapide (plus de 10 fois plus rapides)
Exemples :
- Export GRR
INSERT INTO grr_entry values (38207, 1453728600, 1453735800, ...
INSERT INTO grr_entry values (38208, 1456147800, 1456155000, ...
INSERT INTO grr_entry values (38209, 1459168200, 1459175400, ...
- Export phpmyadmin
INSERT INTO `grr_entry` (`id`, `start_time`, ...) VALUES
(38207, 1453728600, 1453735800, ...
(38208, 1456147800, 1456155000, ...
(38209, 1459168200, 1459175400, ...
Cordialement Jean-Pierre
Connexion ou Créer un compte pour participer à la conversation.
- Yan
- Developpeur GRR
Moins
Plus d'informations
- Messages : 2115
il y a 4 ans 6 mois #2643
par Yan
Réponse de Yan sur le sujet Restauration de la base trop longue
Bonjour Jean-Pierre,
oui, c'est une question que je redoutais. L'analyse du code GRR montre que la sauvegarde n'est pas optimisée.
Cependant, un temps d'exécution de 240sec. me semble court. Les scripts d'importation ne passeront pas, également.
Plutôt qu'améliorer par script, je pensais chercher du côté de mysqldump... quand j'en aurai fini avec tout ce qui est en chantier.
De ton côté, as-tu regardé les derniers commits, tant sur la branche 3.4.1 que sur la branche devel3 ? Cela me semble pas mal, mais j'aimerais des retours de tests avant de publier une 3.4.1d
Cordialement,
YN
oui, c'est une question que je redoutais. L'analyse du code GRR montre que la sauvegarde n'est pas optimisée.
Cependant, un temps d'exécution de 240sec. me semble court. Les scripts d'importation ne passeront pas, également.
Plutôt qu'améliorer par script, je pensais chercher du côté de mysqldump... quand j'en aurai fini avec tout ce qui est en chantier.
De ton côté, as-tu regardé les derniers commits, tant sur la branche 3.4.1 que sur la branche devel3 ? Cela me semble pas mal, mais j'aimerais des retours de tests avant de publier une 3.4.1d
Cordialement,
YN
Connexion ou Créer un compte pour participer à la conversation.
- scoubinaire
- Auteur du sujet
- Membre elite
Moins
Plus d'informations
- Messages : 167
il y a 4 ans 6 mois #2644
par scoubinaire
Réponse de scoubinaire sur le sujet Restauration de la base trop longue
Bonjour Yan, j'ai regardé les derniers commits et installé puis testé le devel3 du 28/04 : tout à l'air bien !
Jean-Pierre
Jean-Pierre
Connexion ou Créer un compte pour participer à la conversation.
Modérateurs: Yan