optimisation requete sql sur mutualisé

[achaternet]

Bonsoir,

deja les caracteristiques:

mon site est dc en mutualisé ainsi pas acces au php.ini

Apache/1.3.29 (Unix) PHP/4.3.3

Zend Optimizer
Optimization Pass 1 enabled
Optimization Pass 2 enabled
Optimization Pass 3 enabled
Optimization Pass 9 disabled
Optimization Pass 10 disabled
Zend Loader enabled

-> eventuellement pour compresser ??

HTTP_ACCEPT_ENCODING gzip, deflate .

Il est en urlrewriting.


Voila donc mon pb ... les pages s affichent en 15s suite a l insertion de pas mal d enregistrements dans ma bdd.

Ainsi, ce que j'ai fait suite a ça:

Division de la page en plusieurs pour alleger la page. ( au depart 300ko!)

Modif requete du genre SELECT * en SELECT nomchamps

Je ne sais pas trop quelle est la fonction la plus rapide sur une requete sur une table qui fait des requetes sur les champs d un table de poids env 1,4 Mo (pour l instant, mais qui augmente..) 3 600 enregistrements pour l instant avec 24 chps differents.

Je ne peux pas utiliser de "cache", car la page se modifie toute seul

Es ce que la compression gzip pourrai aider?

Quelle sont les façons les plus souples a mettre en oeuvre?

merci de precieux conseils

[iconso]

Tu parles de 15 secondes pour affichers une page, il faut savoir si ce temps est destiné à générer la page (requete SQL notamment) ou à la transmettre au navigateur :
- Si génération : ca me parait peu probable vu le faible nombre d'enregistrement dans ta base, mais dans ce cas ton script (ou requete) doit être défaillant quelque part
- Si transfert : alors la compression va pouvoir t'aider, et éventuellement un passage en CSS2 pour ceux qui ne supportent pas cette compression...

Fred

[jeroen]

essaie de faire

Code: Tout sélectionner

<?php
function getmicrotime()
   {
   list($usec, $sec) = explode(" ",microtime());
   return ((float)$usec + (float)$sec);
   }
...
...
$temps_debut = getmicrotime();
... (ta requête sql)
$temps_fin = getmicrotime();
...
print "requête en ".round($temps_fin-$temps_debut,3)." secondes";


pour voir le tps exect de ta requete uniquement.
Perso j'ai des requêtes qui puisent sur 3 tables de 500 Ko chacunes, et ç ne dure que 1/10 ème de seconde (a peu pres).

A tu mis des INDEXS ?

[achaternet]

Tu parles de 15 secondes pour affichers une page, il faut savoir si ce temps est destiné à générer la page (requete SQL notamment) ou à la transmettre au navigateur :
- Si génération : ca me parait peu probable vu le faible nombre d'enregistrement dans ta base, mais dans ce cas ton script (ou requete) doit être défaillant quelque part
- Si transfert : alors la compression va pouvoir t'aider, et éventuellement un passage en CSS2 pour ceux qui ne supportent pas cette compression...

Fred

Comment distinguer? le fait de separer les 2 et ainsi tester chacun, ainsi de comparer le temps total et temps unique de la requete?

Deja ok, vais tester cela, ça me renseignera plus

et le calcul du temps precis avec par expl le code de jeroen

A tu mis des INDEXS ?

cad, c quoi??

[iconso]

Oui, la solution de jeroen te permettra de mesurer le temps de génération précisément. Tu peux effectivement séparer les deux et le mesurer de manière plus approximative en n'affichant pas tes données (et que tu n'auras donc pas a transmettre au navigateur), ou en appelant ta page HTML générée après l'avoir sauvegardée et tranférée sur ton serveur, selon ce que tu veux mesurer.

Un index de base de données fonctionne un peu comme une table des matières, et permet d'accélerer l'accès aux données. Son principal inconvénient réside dans le ralentissement de l'ajout et MAJ des données de ta base.

Fred

[Xethorn]

Bonjour,
Pourquoi ne pas utiliser un système de cache ? ça pourrait faire gagner du temps et éviter des requêtes inutiles ...
@tcho
Xethorn

[sietjp]

Il faut mettre des INDEX sur les champs sur lesquels tu fais des recherches intensives.

[achaternet]

Bonjour,
Pourquoi ne pas utiliser un système de cache ? ça pourrait faire gagner du temps et éviter des requêtes inutiles ...
@tcho
Xethorn

Parce les pages sont ne sont statiquent mais DYNAMIQUE,

ainsi, il faudrait un truc du genre maj auto par expl 2 fois par jour, c relou

Il faut mettre des INDEX sur les champs sur lesquels tu fais des recherches intensives.

ça m en dit pas bcp plus, j ai deja fait modif sur toutes mes requetes qui avait SELECT * par SELECT nom_chps, c est ça que tu parles sietjp et jeroen


Bon là enfin ce soir, je peux faire le test de la durée des 2 tests, dans qq minutes, je vous tiens au courant des resultats

[George Abitbol]

Concernant les INDEX :

http://www.google.com/search?hl=fr&ie=I ... lr=lang_fr
http://www.phpinfo.net/articles/article ... mysql.html

Fred

[achaternet]

Voici les resultats concernant une execution classique de la page, mais en lancant la fct temps de jeroen en differentes etapes d executions des requetes sql de la page.

Je sais deja, par rapport a mes requetes que le plus lourd en requetes est entre calcul I et calcul II

Neanmoins, on constate, que plus il y a d enregistrements dans la table et plus
le delai entre calcul0 et calcul I est important et tant a se rapproche du temps d execution de cacul I a calcul II


158 enregistrements
requête en 0.025 secondes jusque calcul 0
requête en 0.202 secondes jusque calcul I
requête en 0.786 secondes jusque calcul II
requête en 0.83 secondes jusque calcul III


678 enregistrements
requête en 0.041 secondes jusque calcul 0
requête en 2.226 secondes jusque calcul I
requête en 3.525 secondes jusque calcul II
requête en 3.569 secondes jusque calcul III


930 enregistrements
requête en 0.062 secondes jusque calcul 0
requête en 4.92 secondes jusque calcul I
requête en 8.025 secondes jusque calcul II
requête en 8.072 secondes jusque calcul III

[achaternet]

...

ou là là, avec bcp plus d enregistrements, c flagrant:


3 629 enregistrements
requête en 0.913 secondes jusque calcul 0
requête en 111.607 secondes jusque calcul I
requête en 111.609 secondes jusque calcul II
requête en 118.597 secondes jusque calcul III



Au moins je sais quelle requete optimiser, mais bon, je ne peux pas faire bcp plus simple de ce côté , comment faire alors

vais approfondir les index merci fred pour les precisions dessus

[jeroen]

Donne tes requêtes

[achaternet]

yep,

ainsi donc voici la requete principale qui fait souffrir le serveur

qui correspond entre calcul 0 et calcul I, soit l essentielle du temps qd on constate sur un nb important d enregistrements.

Suite a vous precieux conseils, je vais finir d optimiser mes tables.

$kery = "SELECT DISTINCT nom FROM `$sstheme`".$query_add." ORDER BY nom";
$zult = mysql_query ($kery);
while($nprod = mysql_fetch_array($zult)) {
$pech=$nprod->nom;
$kery2 = "SELECT count(revend) FROM `$sstheme` WHERE nom = '$pech'" ;
$zult2 = mysql_query ($kery2);
list($nbre_revendus) = mysql_fetch_array($zult2);
}

Puis je utiliser les index là?

merci encore

[Oncle Tom]

Mouarf c'est normal ... tu fais des requête imbriquées !!
Surtout faut pas faire ça.

Imagine que ta $kery retourne 150 résultats, elle va exécuter ensuite en dessous 150 requêtes SQL supplémentaires (qui seront balayées bien sûr). Y'a rien de mieux pour tuer le serveur.
Fais des jointures sur tes tables et tu pourras faire ça en 1 requête au lieu de plusieurs ...

[achaternet]

Mouarf c'est normal ... tu fais des requête imbriquées !!
Surtout faut pas faire ça.

Imagine que ta $kery retourne 150 résultats, elle va exécuter ensuite en dessous 150 requêtes SQL supplémentaires (qui seront balayées bien sûr). Y'a rien de mieux pour tuer le serveur.
Fais des jointures sur tes tables et tu pourras faire ça en 1 requête au lieu de plusieurs ...

Quel code serait plus "leger" en requete?

En fait la requete dessus permet de calculer tous les enregistrements dont ceux qui sont identique, cad aillant le meme nom dans la table.