Temps de réponse et temps d'affichage
Résolu
cs_Tartuffe
Messages postés
39
Date d'inscription
jeudi 27 mai 2004
Statut
Membre
Dernière intervention
18 février 2008
-
28 mars 2006 à 12:17
cs_Anthomicro Messages postés 9433 Date d'inscription mardi 9 octobre 2001 Statut Membre Dernière intervention 13 avril 2007 - 28 mars 2006 à 19:37
cs_Anthomicro Messages postés 9433 Date d'inscription mardi 9 octobre 2001 Statut Membre Dernière intervention 13 avril 2007 - 28 mars 2006 à 19:37
A voir également:
- Temps de réponse et temps d'affichage
- Emploi du temps scolaire à remplir - Forum PHP
- Diagramme de classe emploi du temps ✓ - Forum Java
- Gestion d emploi du temps en java - Forum Java
- Gestion des emplois du temps sous java et mysql d'une université - Forum Java
- Gestion des emplois de temps - Forum Java
7 réponses
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
28 mars 2006 à 13:07
28 mars 2006 à 13:07
- une boucle de fonctions je pense
- une requête OPTIMISEE, donc à voir au niveau des jointures
- ça dépend du traitement...
- une requête OPTIMISEE, donc à voir au niveau des jointures
- ça dépend du traitement...
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
28 mars 2006 à 12:30
28 mars 2006 à 12:30
Hello,
pourquoi tu ne benches pas les 2 solutions...??
Ceci dit je n'ai pas tout compris : on ne sait pas quels sont tes traitements, ni rien.
Le plus rapide, c'est aussi fonction du code, et de la structure des tables.
Bref comme ça, à vue de nez, sans plus d'infos, la solution 1 sera probablement la plus rapide.
Mais vraiment, il y a trop peu d'infos.
pourquoi tu ne benches pas les 2 solutions...??
Ceci dit je n'ai pas tout compris : on ne sait pas quels sont tes traitements, ni rien.
Le plus rapide, c'est aussi fonction du code, et de la structure des tables.
Bref comme ça, à vue de nez, sans plus d'infos, la solution 1 sera probablement la plus rapide.
Mais vraiment, il y a trop peu d'infos.
cs_Tartuffe
Messages postés
39
Date d'inscription
jeudi 27 mai 2004
Statut
Membre
Dernière intervention
18 février 2008
3
28 mars 2006 à 12:47
28 mars 2006 à 12:47
... en recentrant la question : il vaut mieux faire une chaine de fonctions ou une boucle de fonction ?
Mais cela a t'il un impact significatif en terme de temps de réponse ?
Soit dans le cas ci-dessus :
- F1 avec un résultat partiel, puis appel unitaire à F2 à chaque résultat de F1
vs
- F1 qui fait un appel unitaire à F2 et renvoie un résultat complet, puis traitement de F1
Maintenant, en élargissant la question, car c'était là le fond de ma pensée :
Vaut-il mieux faire une requête complète (avec jointures) qui retourne le résultat final, ou un enchainement de requête simple avec PHP qui boucle pour reconstituer le résultat final.
Le rapide en terme de temps de réponse, c'est PHP ou MySQL ?
"En théorie", qui des 2 doit travailler le plus afin d'améliorer le temps de réponse ?
PekLandais
Mais cela a t'il un impact significatif en terme de temps de réponse ?
Soit dans le cas ci-dessus :
- F1 avec un résultat partiel, puis appel unitaire à F2 à chaque résultat de F1
vs
- F1 qui fait un appel unitaire à F2 et renvoie un résultat complet, puis traitement de F1
Maintenant, en élargissant la question, car c'était là le fond de ma pensée :
Vaut-il mieux faire une requête complète (avec jointures) qui retourne le résultat final, ou un enchainement de requête simple avec PHP qui boucle pour reconstituer le résultat final.
Le rapide en terme de temps de réponse, c'est PHP ou MySQL ?
"En théorie", qui des 2 doit travailler le plus afin d'améliorer le temps de réponse ?
PekLandais
huberdine
Messages postés
158
Date d'inscription
samedi 8 février 2003
Statut
Membre
Dernière intervention
17 juin 2010
28 mars 2006 à 14:34
28 mars 2006 à 14:34
Ce qui est certain, c'est qu'un appele à la base de données (MySql) est couteux, en temps, et en ressources.
L'idéal, c'est d'en faire le maximum en php et d'optimier au maximum tes requêtes MySql avec des jointures afin de n'aller chercher dans la BDD que ce dont tu a besoin.
D'un autre côté, à moins d'avoir des traitements longs (sur plusieurs centaintes d'enregistrements), le temps de traitement Php/MySql sera beaucoup plus court que l'acheminement des données du serveur au navigateur du client.
-*- switch -*-
L'idéal, c'est d'en faire le maximum en php et d'optimier au maximum tes requêtes MySql avec des jointures afin de n'aller chercher dans la BDD que ce dont tu a besoin.
D'un autre côté, à moins d'avoir des traitements longs (sur plusieurs centaintes d'enregistrements), le temps de traitement Php/MySql sera beaucoup plus court que l'acheminement des données du serveur au navigateur du client.
-*- switch -*-
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
28 mars 2006 à 14:45
28 mars 2006 à 14:45
Je ne suis pas certain que, par exemple, créer un libelle particulier à partir de plusieurs champs, avec une expression régulière, un concat ou autre, soit plus long à effectuer directement dans la requête, plutôt que d'aller chercher les champs normalement, et de traiter l'info ensuite via php.
J'ai même de sérieux doutes ;-)
Maintenant, tout est question d'optimisation et du genre de traitement, comme je le disais : ça dépend du traitement.
Convertir une date, par exemple, autant le faire niveau SQL directement. COALESCE est sans doute (je n'ai jamais testé hein mais...j'ai dans l'idée que...) plus rapide que de récupérer le nom du champ et de faire le remplacement voulu en php.
Personnellement, sur un projet actuel, j'ai un traitement de moins de 2 secondes sur 2700 requêtes SELECT avec traitements divers (coalesce justement notamment), sur une base relativement légère il est vrai (les tables ne dépassent pas les 2300 enregistrements). Je suis passé de 7 secondes à moins de 2 en descendant simplement certaines infos, afin de limiter les jointures.
Bref...tout est à tester...et à optimiser. Pour arriver à ce résultat, j'ai benché à tout va!
J'ai même de sérieux doutes ;-)
Maintenant, tout est question d'optimisation et du genre de traitement, comme je le disais : ça dépend du traitement.
Convertir une date, par exemple, autant le faire niveau SQL directement. COALESCE est sans doute (je n'ai jamais testé hein mais...j'ai dans l'idée que...) plus rapide que de récupérer le nom du champ et de faire le remplacement voulu en php.
Personnellement, sur un projet actuel, j'ai un traitement de moins de 2 secondes sur 2700 requêtes SELECT avec traitements divers (coalesce justement notamment), sur une base relativement légère il est vrai (les tables ne dépassent pas les 2300 enregistrements). Je suis passé de 7 secondes à moins de 2 en descendant simplement certaines infos, afin de limiter les jointures.
Bref...tout est à tester...et à optimiser. Pour arriver à ce résultat, j'ai benché à tout va!
huberdine
Messages postés
158
Date d'inscription
samedi 8 février 2003
Statut
Membre
Dernière intervention
17 juin 2010
28 mars 2006 à 15:10
28 mars 2006 à 15:10
J'abonde évidemment dans ce sens là : il vaut mieux une requête SQL un peu complexe
que 1 requête SQL, un traitement puis une seconde requête SQL.
C'est pour celà qu'il faut en faire le maximum en php dans le but de limiter tes requêtes.
Ton approche du code sera différente si tu fais des requêtes à tout bout de champ ou si au contraire tu essaye de faire le moins de requêtes possibles.
-*- switch -*-
que 1 requête SQL, un traitement puis une seconde requête SQL.
C'est pour celà qu'il faut en faire le maximum en php dans le but de limiter tes requêtes.
Ton approche du code sera différente si tu fais des requêtes à tout bout de champ ou si au contraire tu essaye de faire le moins de requêtes possibles.
-*- switch -*-
cs_Anthomicro
Messages postés
9433
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
13 avril 2007
8
28 mars 2006 à 19:37
28 mars 2006 à 19:37
Salut,
en général vaut mieux une seule requête que plusieurs, mais y'a des exceptions... il y a très longtemps j'ai divisé mon temps de génération par deux en augmentant le nombre de requêtes par trois... (bon depuis j'ai tout divisé encore en supprimant les requêtes inutiles suite à un changement d'architecture mais bon...)
C'est pour dire que c'est tellement variable qu'il n'y a pas de réponse valable à ton post, tout au plus pouvons-nous faire des généralités sur les cas les plus probables... bref il ne te reste plus qu'à tester.
a +
<hr size="2" width="100%"><li>Entraide, dépannage et vulgarisation informatique : Mon site de vulgarisation informatique</li><li>Codes-php.net</li>
en général vaut mieux une seule requête que plusieurs, mais y'a des exceptions... il y a très longtemps j'ai divisé mon temps de génération par deux en augmentant le nombre de requêtes par trois... (bon depuis j'ai tout divisé encore en supprimant les requêtes inutiles suite à un changement d'architecture mais bon...)
C'est pour dire que c'est tellement variable qu'il n'y a pas de réponse valable à ton post, tout au plus pouvons-nous faire des généralités sur les cas les plus probables... bref il ne te reste plus qu'à tester.
a +
<hr size="2" width="100%"><li>Entraide, dépannage et vulgarisation informatique : Mon site de vulgarisation informatique</li><li>Codes-php.net</li>