Jump to content

Optimisation des requêtes adressées à MySQL depuis une page PHP


Yhann

Recommended Posts

Bonjour,

Avant, dans mes fichiers PHP, je plaçais en haut de fichier le code PHP nécessaire à l'interrogation d'une base de données. En terme d'optimisation, c'était au top, j'utilisais la séquence suivante :

- connexion à la base

- exécution de la requête 1

- exécution de la requête 2

- exécution de la requête n

- fermeture de la base

Cette séquence permet de limiter le nombre de connexions simultannées à la base. Tout le retse du traitement PHP, la mise en forme des données, etc. est placée après. Concernant la connexion à MySQL, j'utilise une connexion non persistante.

Mais maintenant, je ne peux plus procéder ainsi. J'utilise en effet des "modules" de codes, qui doivent être indépendants. Je les insère où je le veux dans la page, et du coup, je ne peux plus regrouper mon script de communication à MySQL en haut du fichier PHP.

Ma page devient :

- code PHP

- connexion à la base

- exécution de la requête

- fermeture de la base

- code PHP

- code PHP

- connexion à la base

- exécution de la requête

- fermeture de la base

- code PHP

- code PHP

- code PHP

- code PHP

...

En terme d'optimisation, faut-il refermer la connexion à MySQL à chaque fois, ou une seule fois à la fin du script ? Faut-il l'ouvrir à chaque fois ?

Autrement dit, la séquence ci-dessus serait-elle plus optimisée si elle devenait :

- code PHP

- connexion à la base

- exécution de la requête

- fermeture de la base

- code PHP

- code PHP

- connexion à la base

- exécution de la requête

- fermeture de la base

- code PHP

- code PHP

- code PHP

- code PHP

...

Qu'en pensez-vous ?

Merci :)

Link to post
Share on other sites

Bonjour et merci pour vos réponses. Je pense opter pour une unique ouverture et fermeture de la base par page.

Concernant la connexion persistante, non, beaucoup d'hébergeurs mutualisés la déconseillent, en incriminant une surcharge des serveurs MySQL.

S'il y a d'autres avis, n'hésitez pas à les poster :)

A++

Link to post
Share on other sites

Mon avis a 2 cents... :blush:

S'il s'agit d'un ouverture unique mais qu'il s'ecoule une eternite de temps avant la fermeture, ca n'est pas ce qu'il y a de mieux. Au contraire, des zilliards d'ouvertures et de fermetures - en fonction des perfomances de la base de donnees et autres circonstances - peut mechamment alourdir l'execution du script.

Les differences entre les deux approches sont de l'ordre la subtilite.

Qu'importe la methode, la meilleure optimisation reste celle

- de la structure de la base de donnees, des tables et des champs (structure optimale, utilisation des clees primaires, etc.)

- des requetes bien contruites

- d'un code php optimise

:)

Tu peux tester en local avec ApacheBench et eventuellement des outils comme mrtg pour simuler des connections http et suivre la montee en charge.

:)

Link to post
Share on other sites
  • 3 weeks later...

Bonjour.

Personnellement j'ai choisi une autre approche.

Je suis également en train de ré-écrire mon site pour remplacer le vieux phpnuke utilisé.

La technique que j'ai décidé d'employer est de séparer toutes les requêtes MySQL et de les utiliser de la même manière que les modules.

C'est à dire que celles-ci sont chargées en début de traitement en fonction du module appelé.

Je ne sais pas si ce sera réellement plus efficace étant donné qu'il faut alors stocker les résultats dans des objets et/ou des tables, mais ça libère plus rapidement le serveur MySQL qui semble être le goulot d'étranglement.

Par ailleurs je me demande comment vous faites pour supporter plus de 1000 visiteurs simultanés (Vendredi dernier) :?:

Comment sont optimisés MySQL, Apache et PHP ?

Edited by Pulsar-san
Link to post
Share on other sites
Par ailleurs je me demande comment vous faites pour supporter plus de 1000 visiteurs simultanés (Vendredi dernier) :?:

Comment sont optimisés MySQL, Apache et PHP ?

On commence par prendre un gros serveur ;)

Le serveur du Hub est un Bi-Xeon DualCore avec 6GB de RAM, cela peut faire la différence.

Il n'empêche que le code mysql est particulièrement soigné chez Invision !

Et je préfère rester en Apache 1.3 parce qu'il est plus performant que les versions 2.x

Link to post
Share on other sites

Ah vi, évidemment :wacko:

Le mien a 3Go et un Pentium 4 3,2Ghz.

Par contre c'est un Apache 2.x qui tourne.

Ce n'est pas la première fois que j'entends dire que la 1.3 serait meilleure que la 2.x

Je me demande si c'est simple de redescendre vers la 1.3... :unsure:

Peut-être installer les deux et mettre la 1.3 sur le port 8080 pour tester les modifications à faire au niveau des hôtes virtuels.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...