Optimisation de scripts PHP/MySQL [D�bat]

**Blustuff** · 10/07/2007, 13h30

Il est �tonnant que cette optimisation ne soit pas effectu�e par le SGBD. Peut on avoir une liste fiable des SGBD pour lesquels il faut effectivement faire le travail � leur place ?

**berceker united** · 10/07/2007, 15h03

Envoy� par Blustuff

Il est �tonnant que cette optimisation ne soit pas effectu�e par le SGBD. Peut on avoir une liste fiable des SGBD pour lesquels il faut effectivement faire le travail � leur place ?

Je dirais toute celle qui utilise un �quivalent au LIMIT. Mais !...
En fait, il est rare de faire une pagination sur des centaines de milliers d'enregistrements mais pour 10 000 enregistrements je ne pense pas qu'il y ait de probl�me.
La structure d'une base de donn�es peut changer selon la quantit� d'information qu'il doit g�rer.

Pour le LIMIT il est un peut normal que �a mette beaucoup de temps pour une telle quantit� donc il faut passer par une autre technique telle que je site mais il faut pas l'utiliser syst�matique pour un faible volume.

**Blustuff** · 18/07/2007, 19h27

Si l'optimisation peut �tre syst�matique, alors les SGBD la feraient syst�matiquement, vu qu'elle n'est pas excessivement compliqu�e. Quel est le d�tail qui fait qu'ils ne font pas ce travail ?

**berceker united** · 18/07/2007, 20h11

Envoy� par Blustuff

Si l'optimisation peut �tre syst�matique, alors les SGBD la feraient syst�matiquement, vu qu'elle n'est pas excessivement compliqu�e. Quel est le d�tail qui fait qu'ils ne font pas ce travail ?

Test de performance entre les deux methodes avec de fort volume.

**Blustuff** · 19/07/2007, 11h01

Vous ne donnez pas de raison pour laquelle votre m�thode serait moins performante.

**berceker united** · 19/07/2007, 12h17

Envoy� par Blustuff

Vous ne donnez pas de raison pour laquelle votre m�thode serait moins performante.

Laquelle qui serait moin importante ? Utiliser un LIMIT ou le BETWEEN.

Si c'est le LIMIT. Les performances tombent lorsqu'il y a �normement d'enregistrement sur la les tables joints. Par exemple, sur un forum ou le nombre de page d'un topic est compl�tement al�atoire. Sur le site hardware.fr il y a des topic ou il y a un topic sur Sarkozy qui lui poss�de 2993 pages � l'heure ou j'�cris. en sachant qu'il y a 30 interventions par page donc 2993x30 = 89790 enregistrements. La consultation des donn�es vers la page 1,2,3,4,... vont �tre rapide mais vers la fin �a va �tre plus long. Le moteur doit parcourir toute la ou les tables join quasiment enregistrement par enregistrement. Ceci jusqu'a qu'il arrive au bon curseur (num�ro de page) et de la il retourne les x �l�ment par la suite. Dans l'exemple c'est 30. Ce qu'il bouffe aussi c'est qu'il est oblig� de ranger les donn�es par date. Le ORDER BY + LIMIT en m�me temps greffe les perfs.

**Blustuff** · 19/07/2007, 13h05

Non, l'autre m�thode.

**berceker united** · 19/07/2007, 13h08

Envoy� par Blustuff

Non, l'autre m�thode.

Si c'est le BETWEEN, non je concid�re pas que c'est une m�thode moin performant, bien au contraire.
Peut �tre que c'est moi qui m'y suis mal expliqu� ou une coquille.

**Blustuff** · 19/07/2007, 13h27

Mais alors pourquoi cette optimisation n'est pas faite syst�matiquement par les SGBD ?

Dans un SGBD qui autorise les requ�tes imbriqu�es, on pourra �crire �a encore plus concis�ment. Une r�gle qui est assez souvent appliqu�e est de laisser le SGBD optimiser la requ�te et de ne pas faire ce genre de choses. Bien s�r, il peut y avoir des exceptions, mais il faut �tre bien certain de ce que l'on fait, d'o� ma question.

**berceker united** · 19/07/2007, 14h31

Envoy� par Blustuff

Mais alors pourquoi cette optimisation n'est pas faite syst�matiquement par les SGBD ?

Dans un SGBD qui autorise les requ�tes imbriqu�es, on pourra �crire �a encore plus concis�ment. Une r�gle qui est assez souvent appliqu�e est de laisser le SGBD optimiser la requ�te et de ne pas faire ce genre de choses. Bien s�r, il peut y avoir des exceptions, mais il faut �tre bien certain de ce que l'on fait, d'o� ma question.

Oui biensure, ce que je donne peut se faire naturellement dans une requ�te imbriqu� c'est m�me mieux.
Pourquoi ce n'est pas optimis� ? Personnellement, je ne lui reproche pas que �a soit pas optimis� parce que cela n�cessite de prendre beaucoup de param�tre en compte. La taille �ventuelle qui sera retourn�, le nombre de table impliqu� dans la requ�te. De plus, pour en arriver � avoir plus de 2000 pages ... Cela en vaut-il la peine de faire une exception. Par rapport au bench et au developpeur traitant de ce probl�me c'�tait la meilleur solution. Le forum Hardware.fr malgr� qu'il soit sur SQL Server utilise la m�me technique pour les m�mes raisons.

**genova** · 20/07/2007, 09h28

Envoy� par berceker united

Si c'est le LIMIT. Les performances tombent lorsqu'il y a �normement d'enregistrement sur la les tables joints. Par exemple, sur un forum ou le nombre de page d'un topic est compl�tement al�atoire. Sur le site hardware.fr il y a des topic ou il y a un topic sur Sarkozy qui lui poss�de 2993 pages � l'heure ou j'�cris. en sachant qu'il y a 30 interventions par page donc 2993x30 = 89790 enregistrements. La consultation des donn�es vers la page 1,2,3,4,... vont �tre rapide mais vers la fin �a va �tre plus long. Le moteur doit parcourir toute la ou les tables join quasiment enregistrement par enregistrement. Ceci jusqu'a qu'il arrive au bon curseur (num�ro de page) et de la il retourne les x �l�ment par la suite. Dans l'exemple c'est 30..

Tu es s�r ? Moi si j'�tais un SGBD et que je devais retourner les 30 r�sultats � partir de la page 1985, ben je me contenterai de d�placer un pointeur jusque cette zone m�moire et de retourner ce qu'il faut. Apr�s reste � voir le fonctionnement interne de la SGBD, je suis sur que ce sont des programmes bienb bourrins ^^

**berceker united** · 20/07/2007, 14h28

Envoy� par genova

Tu es s�r ? Moi si j'�tais un SGBD et que je devais retourner les 30 r�sultats � partir de la page 1985, ben je me contenterai de d�placer un pointeur jusque cette zone m�moire et de retourner ce qu'il faut. Apr�s reste � voir le fonctionnement interne de la SGBD, je suis sur que ce sont des programmes bienb bourrins ^^

C'est simple PhpBb utilise le LIMIT

c'est pour cela qu'arriver � un certain nombre de page ce forum devient un veau et que beaucoup d'hebergeur ne veulent � avoir ce forum chez eux

.

**genova** · 20/07/2007, 15h36

Merci pour les infos,
je viens de regarder le code source de vbulletin et effectivement ils chargent les messages via un IN () en prenant leurs ID.
J'ai regard� le code source de phpBB3 et ils ont corrig�s ce probl�me aussi, donc phpBB3 ne souffrira pas de ce d�faut.

Me reste plus qu'� modifier la source de mon forum

**berceker united** · 20/07/2007, 16h16

Envoy� par genova

Merci pour les infos,
je viens de regarder le code source de vbulletin et effectivement ils chargent les messages via un IN () en prenant leurs ID.
J'ai regard� le code source de phpBB3 et ils ont corrig�s ce probl�me aussi, donc phpBB3 ne souffrira pas de ce d�faut.

Me reste plus qu'� modifier la source de mon forum

PhpBb3 est apparement un tr�s gros nettoyage millenaire de phpBb. Mais au moment du topic il n'�tait pas encore sortie.

**afrodje** · 21/08/2007, 14h10

Envoy� par Metallic-84s

ob_start();
ob_end_flush();

Je n'ai pas compris � quoi �a servait ?

**berceker united** · 21/08/2007, 16h14

Envoy� par afrodje

Je n'ai pas compris � quoi �a servait ?

En faite, tu g�res la sortie �cran. En faite quand tu fais un echo tu peux retarder l'affichage �cran par exemple ou orienter l'information destin� � l'�cran pour l'envoyer dans une fichier.
C'est utilis� pour la gestion du cache.

**is_null** · 22/08/2007, 19h03

Au sujet de la mise en tampon the sortie (output buffering).
Le principe est simplement que lorsqu'il est d�marr� : le parser garde la main � chaque ?>, ce qui optimise largement la vitesse d'execution proportionnelement au nombre de <?php ?> (notamment pour ceux qui utilisent des templates en PHP).
Si la mise en tampon de sortie n'est pas activ�e, il est logique que PHP rende la main � son module d'execution lorsqu'il parse un ?> (module d'execution comme apache-php, cli ou cgi, ou autre). Lequel lui rend la main si il rencontre une balise d'ouverture <?php ou <? si il en rencontre une ...
En r�gle g�n�rale, la bufferisation de sortie optimise largement le code.

example : http://www.developpez.net/forums/sho...&postcount=287
doc : http://php.net/outcontrol

**Sayrus** · 23/08/2007, 16h34

Bonjour � tous!

J'ai une question pour laquelle vous pourriez peut �tre me r�pondre:

Selon vous, combien de requ�te SQL peut on faire au maximum par page (pour un CMS complet) ?

Comme vous devez le savoir, une seule requ�te pour g�rer un CMS c'est un peu...

Alors pour savoir si je suis dans le bon, dites moi combien de requ�te est il id�al de faire AU MAXIMUM pour un site accueil des centaines de personnes simultan�ment.

Une id�e?

Merci.

**berceker united** · 23/08/2007, 17h14

Envoy� par Sayrus

Bonjour � tous!

J'ai une question pour laquelle vous pourriez peut �tre me r�pondre:

Selon vous, combien de requ�te SQL peut on faire au maximum par page (pour un CMS complet) ?

Comme vous devez le savoir, une seule requ�te pour g�rer un CMS c'est un peu...

Alors pour savoir si je suis dans le bon, dites moi combien de requ�te est il id�al de faire AU MAXIMUM pour un site accueil des centaines de personnes simultan�ment.

Une id�e?

Merci.

Au mieux je dirais 0 !
C'est pas facile � r�pondre � cette question tous d�pend de la logique de la structure de la base de donn�es. Maintenant, il faut pas arriver � 50. Tu devrais pas poser la question dans ce sens l�. Il pr�f�rable de se poser la question sur la logique de metier de ton application que chercher � faire des �conomie de requ�te. Il est pr�f�rable de faire 10 requ�tes optimis� qu'une requ�te de bourrin.

**Sayrus** · 23/08/2007, 18h28

Ok merci

Je vais faire les meilleures requ�tes possibles ou utiliser des caches.

Optimisation de scripts PHP/MySQL [D�bat]

PHP & Base de donn�es

Discussions similaires

Partager

Partager