Optimisation SQL de mon CMS

Invité · 02/10/2013, 23h44

Bonsoir à tous,

Je suis en train de coder un petit CMS perso et la structure peut se résumer à ça :

Ouverture de la connexion SQL
Tout le travail interne du CMS
Quelques requetes SQL etc..
Fermeture de la connexion SQL

C'est le schéma du fichier index.php qui après dans son travail interne, va inclure tel ou tel autre fichier pour les pages sous-jacentes.

Cependant, j'ai l'impression que le temps de chargement d'une page est un peu long..
Dois-je laisser ma co SQL ouverte tout le temps ou l'ouvrir/fermer à chaque requête ?

J'utilise MySQLi

Je précise que c'est un CMS qui, à terme fera beaucoup de transitions de données entre le site et le serveur SQL.

Merci d'avance

**demenvil** · 03/10/2013, 10h34

Salut pour optimiser déjà ton code :
Au niveau de tes requêtes utilise tu les jointure ?
Sélectionne tu uniquement les champs dont tu as besoin
Met tu les informations importantes en session pour ne pas à avoir à les redemander au serveur de bdd ?Met tu en cache tes requêtes ?
Est-ce que tes clauses where ne sont pas trop lourde ou trop "vague" ?

Pour ma part c'est je pense que c'est une bonne chose d'ouvrir la co en haut de script et la fermé en bas, ceci donc sur ton index.php.

Invité · 03/10/2013, 11h22

Salut,

Merci de ta réponse.
Comment mettre en cache les requêtes ?
Etant donné que mes sessions sont stockées en SQL pour avoir plus de sécurité, mettre des infos en session revient au même

++

**demenvil** · 03/10/2013, 11h44

Pour le cache SQL :
http://php.net/manual/fr/mysqlnd-qc....rt.caching.php
http://dev.mysql.com/doc/refman/5.0/fr/query-cache.html
http://dev.mysql.com/doc/refman/5.0/...iguration.html

Histoire que tu te fasse la main

N'hésite pas non plus a activer l'extension APC de php

Cela optimise également le temps de chargement des pages.

Pour de ce qui est les sessions en bdd, je ne suis pas trop fan, ça fait trop de traitement pour peu je trouve.. Certain framework comme CodeIngiter se serve de cette méthode mais j'en change constamment le fonctionnement.

Si tu sécurises bien tes dev's, tu peux protéger tes sessions sans problème et ainsi en éviter le vol etc..

Invité · 03/10/2013, 14h44

Et si je veux sécuriser mes sessions parfaitement sans passer par SQL, je dois faire comment ?

L'avantage des sessions SQL est que les utilisateurs peuvent les killer à distance..
C'est possible de faire ça avec des sessions classiques ?

Merci

**demenvil** · 03/10/2013, 14h57

Ce que des fois moi je fait, je change déjà le répertoire des session , quasiment impossible à faire si tu es sur un mutu car peu de chance d'avoir accès au php.ini..

Les killer à distance ? Si elle ne sont pas en bdd ? Je pense pas que ce facilement faisable effectivement

Invité · 03/10/2013, 18h05

Je me suis mal exprimé

Je sais que c'est faisable mais ce qui me parait moins faisable, c'est de lister les sessions ouvertes ^^

En tout cas merci de ton aide.

**ABCIWEB** · 04/10/2013, 00h17

Ce qui me paraît bizarre dans cette histoire c'est que le temps d'attente que tu trouve long soit imputable à tes requêtes.
Dans un petit cms il faudrait vraiment mal s'y prendre pour que cela soit le cas. Aussi la question est : as-tu fais des bench pour voir le temps de réponse de tes requêtes ? Il est fort probable que les pb viennent d'autre part.

Sinon évidemment il ne faut pas fermer la connexion après chaque requête mais à la fin de la dernière requête effectuée. Le plus simple est encore de ne rien fermer du tout car php s'occupe très bien de ça tout seul et sauf très rares exceptions, c'est bien plus efficace de laisser faire php (et au passage moins prise de tête) que de déclarer soi-même un mysql_close.

**scvo.0ne** · 04/10/2013, 07h17

Si le problème de perf vient de mysql, c'est peut être simplement une histoire d'index.

Ou tout simplement un serveur mutualisé un peu mou

Invité · 04/10/2013, 19h21

J'ai fait un petit benchTest de mon CMS avec les fonctions microtime

2 s de chargement avec sessions en DB
1 s de chargement avec sessions classiques

Ca vous parait long ?

Merci

**scvo.0ne** · 04/10/2013, 21h01

1 seconde c'est énorme. Ton bench a executé combien de requêtes SQL pour arriver à ces temps là ?

Tu fais les tests sur quels genre de serveur ?

Invité · 04/10/2013, 21h33

Comment on compte le nombre de requête ?
C'est un serveur WAMP local(je précise que j'ai une très bonne config)

**ABCIWEB** · 04/10/2013, 21h48

Oui enfin cela dépend si tu mesure le temps d'affichage ou juste le temps d'exécution de la requête.

Un temps de réponse (pour un affichage complet) d'environ 1 seconde est plutôt dans la moyenne. J'ai lu (je ne sais plus où) que l'ipv6 était la cause du ralentissement de wamp par rapport à l'utilisation de l'ancienne norme. Tu devrais pouvoir trouver de la doc là dessus.

**papajoker** · 04/10/2013, 21h48

Envoyé par Darreugne

Comment on compte le nombre de requête ?

dans phpmyadmin
page accueil - onglet - Etat

la j'ai une grosse phrase :

Statistiques sur les requêtes: Depuis son démarrage, 276 requêtes ont été envoyées au serveur;

Invité · 04/10/2013, 21h55

Alors j'ai lancé un graph avec actualisation toutes les secondes

En moyenne c'est entre 5 - 10 requetes
Lorsque je me connecte à mon CMS on est à environ 18
Lorsque j'ouvre une page quelconque on est à environ 20-25

Invité · 04/10/2013, 23h06

Désolé du double post..

J'ai fais le test avec un mutualisé, temps de réponse du benchTest : 0.07 secondes

Cela vient donc de WAMP(le temps de chargement) comment augmenter la puissance de WAMP ?

Merci d'avance

**papajoker** · 04/10/2013, 23h12

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Cela vient donc de WAMP(le temps de chargement) comment augmenter la puissance de WAMP ?

apache-php est optimisé pour linux et pas pour windows, donc wamp est plus lent (a machines égales).
En local vous avez plus d'extensions de chargées (xdebug,mysql,...) mais en environnement de développement le temps ne compte pas (par exemple pas de cache en dev is good), ça ne sert à rien de changer les configuration d'apache , mysql ou php.