Optimisation requete sql sur mutualisé

achaternet · 10 Juin 2004

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:

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

:arrow: 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 :cry:

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 · 11 Juin 2004

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 · 11 Juin 2004

essaie de faire

Code:

<?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 · 11 Juin 2004

iconso a dit:
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?

:arrow: 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 · 11 Juin 2004

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 · 11 Juin 2004

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 · 11 Juin 2004

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

achaternet · 11 Juin 2004

Xethorn a dit:
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

sietjp a dit:
Il faut mettre des INDEX sur les champs sur lesquels tu fais des recherches intensives.

:roll: ç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 · 11 Juin 2004

Concernant les INDEX :

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

Fred

achaternet · 11 Juin 2004

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 · 11 Juin 2004

...

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

8O 8O 8O

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 · 11 Juin 2004

Donne tes requêtes

achaternet · 12 Juin 2004

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 · 12 Juin 2004

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 · 12 Juin 2004

The Jedi a dit:
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.

Oncle Tom · 12 Juin 2004

Code:

$zult = mysql_query ("SELECT nom, COUNT(revend) as nbre_revendus FROM `$sstheme`".$query_add." GROUP BY nom ORDER BY nom");

while($nprod = mysql_fetch_array($zult)) {
echo $nprod['nbre_revendus'];
}

Maintenant c'est pas dit que ça marche pque je ne connais pas la structure de ta table et ce que tu en fais mais voilà.

PS : tu me fais passer Grand googler pour une requête SQL ^^ qui dit mieux ?

achaternet · 12 Juin 2004

The Jedi a dit:
PS : tu me fais passer Grand googler pour une requête SQL ^^ qui dit mieux ?

C est avec plaisir que je te fais passer grand gg :wink:

Je vais tester ton code, ça devrait le faire

Merci encore

achaternet · 12 Juin 2004

HOUraaaaaaaaaaaaaaaaaaaa

:lol: :lol: :lol:

Gain : temps divisé par 10 :!: :!: :!:

passé de 110s a 14s

(y)

trop content

Digit · 13 Juin 2004

N'oublie pas de mettre un index sur le champs "nom"

achaternet · 14 Juin 2004

Digit a dit:
N'oublie pas de mettre un index sur le champs "nom"

Justement, je me demande tj vis a vis du fameux index...

J'ai optimisé mes tables, specifié une taille pour chaque chps, mais malgré ce que j ai pu lire jusqu alors, je ne pas encore bien compris l index des champs. Je comprend essaiement son principe et egalement l application dans ce cas precis par expl, mais par contre pour le creer , hummm, ché pa encore.

Digit, si tu pouvais m orienté sur le theme des index, disons là pour le champs nom?

:roll: :roll:

Digit · 14 Juin 2004

Un long article :
-http://www.sitepoint.com/article/optimizing-mysql-application/3

Oncle Tom · 14 Juin 2004

Et l'index te fera gagner encore plus de temps (une clé primaire est indexée déjà). Faut qu'il soit pas pris au hasard sinon ça peut au contraire ralentir le temps d'interrogation de ta table !

achaternet · 14 Juin 2004

The Jedi a dit:
Et l'index te fera gagner encore plus de temps (une clé primaire est indexée déjà). Faut qu'il soit pas pris au hasard sinon ça peut au contraire ralentir le temps d'interrogation de ta table !

create unique index nom_de_lindex on nom_de_table (nom_du_champs asc);

Soit

create unique index speedos on informatique (nom);

avec speedos le nom de l index et informatique, le nom de la table et (nom), le nom du chps.

C est bien cela??

achaternet · 15 Juin 2004

pour infos:

optimisation de ma principale requete:

111s -> 14s
Puis insertion d un index, suite aussi a vos conseils et:

111s -> 14s -> .8s (en moyenne)

soit un gain de plus de 110 fois :!: :!:

ça c est de l optimisation

Magnifique :lol:

Oncle Tom · 17 Juin 2004

Ouaip en tous cas 8 secondes ça reste beaucoup magré tout ^^ j'ai pour principe de ne pas dépasser 0.1 seconde dans la génération de mes pages.
Pour les requêtes, normalement un temps de génération se situe en dessous de 0.001 seconde ...

George Abitbol · 17 Juin 2004

C'est 0.8 secondes, qu'il a écrit, pas 8 secondes.

Fred

Oncle Tom · 17 Juin 2004

Et gnééééééé j'ai du mal le matin moi.
Ouais là en effet c'est achement mieux ^^