Discussion :

[gui80]

Bonjour à tous,

j'aimerai effectuer une tâche quotidienne avec des instructions php en dialogue avec la BdD.
Mon collègue a déjà fait des essais il y a quelque temps en php pur. Le serveur était mis à rude épreuve, et perturbait son utilisation.

En gros, pour simplifier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
<?php
for(diag = 0  ;  diag < 500  ; diag++)
   ReactualiseElements(diag); 
?>

La fonction ReactualiseElements prend plus ou moins 30 secondes.
Du coup, le traitement total dure très longtemps !

Faudrait-il pour un traitement aussi lourd, faire autrement ? passer par (diag) N traitements ajax ?

Désolé si mes propos sont idiots, c'est juste que je me demande par où commencer.


Merci d'avance.

[stealth35]

fait plutôt un système de queue

[Benjamin Delespierre]

Tout à fait, il faudrait également déterminer si une optimisation n'est pas possible en identifiant les bottlenecks.

[gui80]

Merci pour les réponses.

J'avoue par contre ne pas encore savoir comment faire pour le système de queue. En PHP ? Je vais chercher un peu.

Pour les goulots d'étranglement, c'est pour essayer de réduire le temps d'exécution de la fonction "ReactualiserElements(diag)" ?
Cela va demander énormément en sachant le nb de vues de calculs sollicités dans cette fonction.
Tu utilises quelque chose de précis pour repérer les bottlenecks ? (logiciels d'analyse de fonctions SQL explain pour postgresql par exemple)

[stealth35]

regarde du coté de RabbitMQ

[Benjamin Delespierre]

Tu utilises quelque chose de précis pour repérer les bottlenecks ? (logiciels d'analyse de fonctions SQL explain pour postgresql par exemple)

Oui mais pas seuelement, tu peux aussi décortiquer les grinds d'execution de PHP avec Webgrind ou WinGrind (ces fichiers de profiling peuvent être produits par un débugger comme ZendDebug ou xdebug).

Pour faire des queues de traitement, je ne sais pas trop, ça va dépendre de la forme de ton application, de la fréquence d'actualisation souhaité, des contraintes de performances etc.

[gui80]

Bonsoir à tous,

en fait, ce qu'il faut optimiser, c'est les requêtes, il faut que je comprenne au mieux les plans d'exécution de l'optimiseur de PostgreSQL.

J'avoue avoir du mal à trouver des tutoriaux complets sur le sujet.
Celui-ci parle de la base pour analyser un EXPLAIN :
http://blog.sdewitte.net/post/2010/1...A-explain-plan

S'il y en a d'autres, plus complets, je suis preneur.
En général, c'est le manque d'index qui est souvent négligé dans la constitution des tables SQL non ?

[Benjamin Delespierre]

Tu as cet article qui traite du sujet. Bonne lecture.

[gui80]

Merci Benjamin.

Il faudra que j'essaie de lire cela au plus tôt.
Voir la config du serveur, elle ne doit pas être assez bien configuré, mais j'avoue ne jamais m'y être intéressé !
Mais il le faudrait, on est bien d'accord.

[Benjamin Delespierre]

Y'a pas que la config du serveur, y'a aussi l'optimisation des tables, des indexes, des clés étrangères et des requêtes

Par ailleurs pour une modélisation correcte je te recommande d'adopter l'usage des formes normales: http://en.wikipedia.org/wiki/Databas...n#Normal_forms