2010-08-03 5 views
4

J'utilise le module Assistant Tableau + Migrer pour importer des noeuds dans mon installation Drupal.Importer 60 000 noeuds

J'ai besoin d'importer environ 60 000 questions/réponses (ce sont les deux nœuds) et je pensais que cela aurait été une tâche facile. Toutefois, le processus de migration importe 4 nœuds par minute et il faut environ 11 jours pour terminer l'importation.

Je me demandais si je pouvais le faire plus rapidement en important directement dans mysql. Mais j'ai réellement besoin de créer 60 000 nœuds. Je suppose que Drupal va stocker des informations supplémentaires dans d'autres tables ... et ce n'est pas si sûr.

Que me suggérez-vous de faire? Attendez 10 jours? Merci

+0

Pouvez-vous poster le script que vous utilisez actuellement, comment l'exécuter? – googletorp

+0

Eh bien, j'utilise le module Migrate (drupal.org/project/migrate). Avec le module Assistant Tableau, j'ai créé les vues avec le contenu de la table externe, puis je l'ai importé dans les nœuds Drupal (seulement 2 champs CCK par nœud, uniquement du texte). Vous avez raison, c'est très lent ... 4 nœuds par minute. Avant c'était 10 nœuds par minute. Votre vitesse de 300 nœuds en quelques secondes est incroyable pour moi. – aneuryzm

+0

Quelle est la source de votre IMPORT? Est-ce un fichier csv sur votre ordinateur. – Nikhil

Répondre

7

La migration de la table doit être plus rapide que celle-ci.

Utilisez-vous pathauto? Si oui, essayez de désactiver le module pathauto, ce qui entraîne souvent de gros problèmes de performance lors de l'importation.Deuxièmement, si la désactivation de pathauto ne fonctionne pas, désactivez tous les modules non essentiels que vous pouvez avoir en cours d'exécution - certains modules font des trucs fous. Éliminer les autres modules en tant que sources du problème.

Troisièmement, le journal de base de données MySQL est-il activé? Cela peut avoir un grand impact sur les performances - pas le niveau dont vous parlez, mais c'est quelque chose à considérer. Troisièmement, installez xdebug, et insérez votre journal mysql pour voir exactement ce qui se passe.

Quelle est votre limite de mémoire PHP?

Avez-vous suffisamment d'espace disque?

+0

VOUS ROCK. Le problème était pathauto en effet. Maintenant, il fonctionne vite: 1967 nœuds/minute. Je vais activer le chemin automatique après l'avoir importé. Merci beaucoup! – aneuryzm

+0

C'est le même impact pour l'importation de l'utilisateur? –

1

Si vous ne le faites pas, vous devez utiliser drush pour migrer les nœuds par lots. Vous pouvez même écrire un script shell pour cela, si vous le voulez automatisé. L'utilisation de la ligne de commande devrait réduire le temps d'importation des nœuds. Avec un script, vous pouvez en faire une tâche automatisée dont vous n'avez pas à vous inquiéter. Une chose que je tiens à noter cependant, 4 nœuds par minute est très faible. Une fois, j'ai dû importer des nœuds à partir d'un fichier CSV, en utilisant migrate etc. J'avais besoin d'importer 300 nœuds, avec l'emplacement, 4-5 champs CCK et je l'ai fait en quelques secondes. Donc, si vous importez seulement 4 nœuds par minute, vous avez soit des nœuds extrêmement complexes, soit quelque chose de louche.

Quelles sont les spécifications de l'ordinateur que vous utilisez pour cela? Où se trouve la source d'importation?

+0

1) J'utilise le script PHP du module Migrate, si je peux exécuter son script depuis Drush (je ne sais pas comment), je peux le faire avec Drush à partir du terminal. 2) J'utilise MacBook Dual Core (32 bits), 2 Go de RAM. 3) La source d'importation est 2 tables dans la même base de données Drupal. – aneuryzm

1

Ceci est un sujet difficile, mais au sein de Drupal en fait très bien couvert. Je ne connais pas les tenants et les aboutissants. Mais sais où regarder.

  • Data Mining Drupalgroup a quelques pointeurs, des connaissances et des informations sur le traitement de grandes quantités de données en PHP/Drupal.
  • Le noyau Drupal a une fonctionnalité par lots built in et est appelé BatchAPI À votre service lors de l'écriture de modules! Pour un exemple de travail, voir this tutorial on CSV import.
0

4 nœuds par minute est incroyablement lent. Migrer ne devrait normalement pas prendre autant de temps. Vous pouvez accélérer les choses en utilisant Drush, mais probablement pas assez pour obtenir un temps d'importation raisonnable (heures, pas jours). Cela ne réglerait pas vraiment votre problème de base: votre importation elle-même prend trop de temps. L'overhead de l'interface graphique de Migrate n'est pas énorme.

L'importation directement dans MySQL serait certainement plus rapide, mais il existe une raison pour laquelle Migrate existe. Le stockage de la base de données des nœuds dans Drupal est compliqué, il est donc généralement préférable de laisser Drupal s'en occuper plutôt que d'essayer de comprendre ce qui se passe. Utilisez-vous les hooks de Migrate pour effectuer des traitements supplémentaires sur chaque nœud? Je suggère d'ajouter un enregistrement pour voir ce qui prend si longtemps. Testez-le sur 10 nœuds à la fois jusqu'à ce que vous compreniez le décalage avant de faire le tout 60k.

+0

Ouais c'est lent: Importé 2 en 28,7 sec (4/min) - continue avec 'réponses d'importation'. Je ne fais pas de traitement supplémentaire. Il suffit d'importer les lignes d'une table vers des nœuds d'un type de contenu spécifique (et d'affecter 3 champs CCK). Comment puis-je ajouter de la journalisation? – aneuryzm

0

Nous avons eu un problème similaire sur une installation Drupal 7. A gauche, il exécute tout le week-end sur une importation, et il n'a importé que 1 000 lignes d'un fichier.

Le plus drôle est que exactement la même importation sur une machine de pré-production prenait 90 minutes.

Nous avons fini par comparer le code source (en vous assurant que nous sommes au même engagement dans git), le schéma de base de données (identique), la quantité de noeud sur chaque machine (pas identiques, mais similaires) ...

Longue histoire faite courte, la seule différence significative entre les deux machines était l'option max_execution_time dans le fichier de paramètres php.ini.

La machine de production avait max_execution_time = 30, alors que la machine de pré-production avait max_execution_time = 3000. Il semble que le module migrate ait une sorte de système pour gérer "court" max_execution_time qui n'est pas optimal.

Conclusion: définissez max_execution_time = 3000 ou plus dans votre php.ini, ce qui aide beaucoup le module de migration.

0

Je voulais juste ajouter une note disant que le pathauto disable aide vraiment. J'avais une importation de plus de 22k lignes et avant de la désactiver, cela prenait plus de 12 heures et tombait en panne plusieurs fois pendant l'importation. Après avoir désactivé pathauto et ensuite exécuté l'importation, il a fallu seulement 62 minutes et ne s'est pas écrasé une fois.

Juste un heads up, j'ai créé un module qui, avant le début de l'importation, désactive le module pathauto, puis à la fin de l'alimentation, réinstalle le module pathauto. Voici le code du module dans le cas où quelqu'un doit avoir cette capacité:

function YOURMODULENAME_feeds_before_import(FeedsSource $source) { 
    $modules = array('pathauto'); 
    drupal_set_message(t('The ').$modules[0].t(' has been deployed and should begin to disable'), 'warning'); 
    module_disable($modules); 
    drupal_set_message(t('The ').$modules[0].t(' module should have been disabled'), 'warning'); 
} 

function YOURMODULENAME_feeds_after_import(FeedsSource $source) { 
    $modules = array('pathauto'); 
    module_enable($modules); 
    drupal_set_message($modules[0].t(' should be reenabled now'), 'warning'); 
} 
Questions connexes