lancer des batch

[julienr]

tiens aller je vais répondre

En general, on fait la premiere grosse mise a jour en local si l'on n'a pas un serveur dédié perso, puis ensuite les mise a jour des derniers éléments se font en ligne.
donc pas besoin de set_time_limit().

là il dit qu'il a un VDS, il est libre, sauf qu'il a pas la puissance d'un dédié

Puis "ensuite pourquoi pas temporiser avec sleep(1) que le moteur ne chauffe pas trop" ca fait bricolage. Tu compte avoir une fenetre en permanante overte pour tes mise a jour ?

non non y a la clim en générale

[KOogar]

20000 entrées sur un fichier texte, c'est pas la mort pour php

je pense que le probleme vient du parseur xml

rog

pourquoi un probleme de parseur ?

et si chaque "entrées" fait 100 Ko ?
100 * 20 000 = 2 000 000 ko = 200 Mo

c'est pas dur de comprendre qu'aucun cas n'est identique et que l'on ne peut pas faire de generalité...

Puis "ensuite pourquoi pas temporiser avec sleep(1) que le moteur ne chauffe pas trop" ca fait bricolage. Tu compte avoir une fenetre en permanante overte pour tes mise a jour ?

non non y a la clim en générale

Au moin on l'air conditionné !!

[YoyoS]

if ($chaud)
$clim = 1;

c'est ça l'air conditionné ?

[rog]

@KOogar

et si chaque "entrées" fait 100 Ko ?
100 * 20 000 = 2 000 000 ko = 200 Mo

c'est cairement hors contexte, ils s'agit d'un xml d'un catalogue de 20 000 produits, sont poids doit beaucoup plus s'approcher de 2 MO que de 200 MO

et je suis persuadé que c'est la façon dont le script php traite le xml qui ralenti le server

rog

[KOogar]

@KOogar

et si chaque "entrées" fait 100 Ko ?
100 * 20 000 = 2 000 000 ko = 200 Mo

c'est cairement hors contexte, ils s'agit d'un xml d'un catalogue de 20 000 produits, sont poids doit beaucoup plus s'approcher de 2 MO que de 200 MO

et je suis persuadé que c'est la façon dont le script php traite le xml qui ralenti le server

rog

si ta 3000 kanards qui vont lire en meme temps le meme flux, faut pas s'etonner que ca rame aux heures de pointes... aspirer les données et les retraiter est la meilleure parade à ce genre de probleme...
on s'en fout du parseur, ils ont tous le meme algo de base...

[rog]

@koogar

si ta 3000 kanards qui vont lire en meme temps le meme flux,

t'es encore une fois hors contexte :

il n'y en a pas 3000 ni 300 ni même 30 personnes qui accèdent simultanément au fichier

j'ai personnellement regardé le code de plusieurs parseurs xml en php et il m'est clairement apparu que l'aspect "ressources utilisées" a été fortement négligé

à la suite de quoi je rajouterai que mysql n'est pas forcément la meilleure solution pour la rapidité de traitement de données

[KOogar]

@koogar

si ta 3000 kanards qui vont lire en meme temps le meme flux,

t'es encore une fois hors contexte :

il n'y en a pas 3000 ni 300 ni même 30 personnes qui accèdent simultanément au fichier

il s'agit d'un catalogue de e-commerçant dont il est affilié. Si c'est -sony, ca depasse alegrement les 3000...
tu es trop casse coui.. a toujours prendre le contre pied, on avance pas.

[rog]

c'est pas l'histoire d'etre casse couil..

si tu sors du contexte tu ne peux pas diagnostiquer

tu multiplies par 100 la première contrainte et par 100 la deuxème

rog

[KOogar]

c'est pas l'histoire d'etre casse couil..

si tu sors du contexte tu ne peux pas diagnostiquer

tu multiplies par 100 la première contrainte et par 100 la deuxème

rog

ok, je te laisse le dernier mot a moi l'apéro !!

je []