blocage site lors mise à jour de fichiers XML

[Baobab]

Bonjour,

Je dispose d'un site intégrant plusieurs catalogues produits XML en provenance de plateformes d'affiliation.

Un script permet de télécharger les fichiers XML mis à disposition par les plateformes d'affiliation et de mettre à jour les produits dans une base MySQL.

Mon pb est que l'opération de mise à jour d'un fichier XML de 9 000 produits environ me prend 11 minutes minimum. Et que la plupart du temps, l'opération de MAJ bloque totalement le site pour les internautes. Le site ne redevient dispo que lorsque l'opération de MAJ est terminée. Aucun trafic sur le site actuellement.

J'utilise un serveur avec 256 Mo de RAM dédié et 5 Go de disque également dédié et une bande passante de 5 Mb/s (serveur en mode Cloud Computing).

Est ce que ce pb de lenteur et de blocage peut provenir du serveur pas assez performant (manque de RAM) ou est ce mon script de MAJ qui est (très) mal conçu ?

Est ce que l'utilisation de fichiers .csv à la place de fichiers XML ne demanderait pas moins de ressources serveur ?

Merci pour vos retours d'expériences sur ce sujet (temps d'execution que vous constatez lors de vos mise à jour, caractéristiques du serveur utilisé).

Cordialement

[jcaron]

Sans avoir les détails du script et de ce qu'il fait (transactions, locks) ni les détails de la base (en particulier si les tables sont en myisam ou innodb), difficile de se prononcer sur quoi que ce soit...

Jacques.

[Baobab]

Le site utilise xmlreader. Pas de transaction. Les tables sont en myisam.

Le script écrase les données des produits de la version N-1 présents dans une table MySQL et les remplace par la version N fournie via un fichier XML (URL du fichier XML fournie par la plateforme d'affiliation). Seules les photos ne sont pas supprimées puis rechargées si elles sont identiques entre les 2 versions (seules les photos sont comparées entre version N et N-1, tous les autres champs des produits sont écrasés systématiquement).

N'ayant pas développé moi même le code, je n'ai malheureusement pas bcp plus d'info ce soir. Une idée ou une piste de recherche néanmoins ?

[jcaron]

S'il n'y a pas de transaction, alors "j'efface tout et je remets tout" ça impliquerait a priori que pendant un temps les scripts qui accèdent en lecture à la base ne trouvent rien. Donc soit il y a bien une transaction, soit l'update est un peu trop sauvage et sature le serveur. Et s'il y a une transaction, sauf erreur myisam et les accès concurrents c'est pas trop ça (pas ma spécialité mysql, moi je suis plutôt postgresql), ceci expliquerait donc cela. Si c'est bien ça, il y a plusieurs options:

- passer en innodb

- au lieu d'effacer tout et de recommencer, mettre les nouvelles données dans une nouvelle table, puis remplacer l'ancienne table par la nouvelle

- optimiser le script pour qu'il ne fasse que les modifications nécessaires plutôt que de tout remplacer

Jacques.

[Baobab]

Merci pour ces conseils.

Je vais tenter les 2 premières options, la 3e ayant déjà été mise en place initialement mais générait des temps d'exécution plus long encore (comparaison du contenu de chaque champs d'un produit pour déterminer les modifications => très long).

[Dadou]

Pour la comparaison, c'est pas bon ta méthode, au produit, tu ajoutes champs date_derniere_modification que tu mets à jour par trigger lors d'un update sur l'enregistrement, et après tu n'exportes que les enregistrement dont la date de dernière modification est ultérieur à la date du dernier export

edit c'est un connerie, ce n'est pa possible par xml

[Baobab]

OK pour la méthode en théorie, mais cela ne peut fonctionner que si le catalogue XML fourni par la plateforme d'affiliation inclut une date de dernière modification, que je pourrais comparer effectivement avec le champs date-derniere-modification de ma table. Hors cette info n'est pas inclue dans le fichier XML fournit par la plateforme d'affiliation

Sinon, il y a l'instruction LOAD DATA INFILE qui semble attractive pour de gros fichiers, mais je crois que cela pose qq pbs de sécurité qui a conduit certains hébergeurs à l'invalider sur leurs serveurs.

[ricardo]

Ne pourrais-tu pas couper la poire en deux en faisant une 'mise à jour sauvage' ? Si je comprends bien en ce moment tu efface tout pour tout réinsérer. Pourquoi ne pas tout mettre à jour sans forcément vérifier s'il y à eu des modifications (se qui serais le mieux) ? Enfin si tu peux relier tes ID produits aux différents noeuds XML.