Etude des optimisations possible du code PHP
Ressources pour l'optimisation
Système de Purge
Voir aussi
ProtectionContreLeVandalisme
Optimisation : éviter les écueils de PHP
Différents types d'optimisations en PHP:
- ConseilsDeProgrammationPhP
- optimisation "haut niveau": bottlenecks, différents systèmes de cache, etc. :
- optimisation en fonction de l'implémentation de php :
Optimisation : calcul de la date de purge via php
Objectif : Optimiser la requête en calculant la date à l'aide de PHP au lieu de
MySQL.
MySQL évalue une seule fois le NOW() pour toute la requête, mais on peut suppose qu'à chaque nouvelle entrée dans la table a ou la table b, elle recalcule le DATE_SUB et le INTERVAL, malgré que ce soit toujours la même valeur... Cela réduit considérablement le nombre de calculs côté
MySQL.
--
LordFarquaad
Pour avoir la date de purge (sans se soucier du fuseau horaire) :
- $purge_date = date('Y-m-d H:i:s', time() - $days * 86400);
- Cette date est normalement retournée en utilisant le fuseau horaire du serveur, qui devrait être le même que pour mysql (sauf si le serveur mysql se trouve ailleurs...)
- LordFarquaad
Remarques :
Le seul truc c'est qu'il faudrait faire attention au timezone (fuseau horaire du serveur), puisque les pages sont sauvées avec le tz du serveur. A noter qu'à l'échelle de 90 jours, supprimer les pages avec une heure ou deux d'avance ou de retard (une demie journée au pire) ne serait pas trop grave je pense, c'est donc peut-être négligeable...
Autre solution : récupérer la date de purge dans une première requête et de la réinsérer dans le select. Il faudrait faire des tests pour voir quel est le plus performant (les requêtes en elles-mêmes seraient plus performantes, mais ce qui prend le plus de temps c'est la communication entre le module php et le serveur mysql...)
--
LordFarquaad
Problème fréquent : lorsqu'une horloge déraille, elle revient à la date de 01-01-1980 (ou 1970 je ne sais plus) : dans ce cas le risque est bien réel. Franchement je ne souhaite pas du tout prendre ce risque.
--
CharlesNepote
- En principe ça revient au 1970-01-01 = Epoch = "naissance" de Unix. Ok, ça arrive fréquemment sur les vieux PC, dont la batterie (ou la pile CR-2032 de nos jours) ne fonctionne plus. Mais ça n'est pas sensé arriver sur un serveur un tant soit peu sérieux ! D'autant plus que tout serveur correctement installé doit se mettre à l'heure au démarrage, puis synchroniser son horloge régulièrement (via NTP par exemple : apt-cache show ntp-simple). Donc pour ma part, je ne gérerai pas ce genre de problème. Sinon, autant essayer aussi de gérer les barrettes mémoire défectueuses... ;-)
- ProgFou
- Tout à fait d'accord. A la limite faire une requête pour récupérer le NOW() et le réinsérer ensuite s'il y a un gain de performance, mais sinon je pense que le mieux est de calculer cela en php. (en fait je trouve que les dates auraient dû toujours être calculées via php, étant donné que c'est php et non mysql qui traite la majeure partie des données, notamment l'affichage)
- LordFarquaad
Optimisation : purge conditionnelle
Par contre ce qui pourrait être intéressant c'est une purge conditionnelle : dans certains cas on n'effectue pas la suppression car le script "estime" que ça n'en vaut pas le coup (par exemple faire une requête pour supprimer moins de x pages ne serait pas assez intéressant)
- Oui, pourquoi pas. Peux-tu préciser les cas ? Pour le fait de ne pas supprimer moins de x pages, ce qui m'ennui c'est qu'on ne respecte donc pas le délai de purge (mais est-ce si important ?) (et encore : il est possible qu'à 8 heures du matin on ai 6 pages à supprimer et 19 pages à 20 heures : ce qui ferait que toutes les pages seraient bien supprimées dans la journée). -- CharlesNepote
En fait je pensais principalement au fait de ne pas purger quand il y a trop peu de pages à supprimer (avec une nombre minimum choisi par l'utilisateur), mais l'idéal serait probablement une estimation plus complexe basée sur différentes choses:
- Le temps écoulé depuis la date de dernière purge
- La charge du serveur (mais difficile à estimer pour un serveur mysql distant...)
- Le nombre de pages éditées au cours des x derniers jours, semaines, mois (si on est dans une période d'activité intense, alors on peut laisser la purge se faire lors d'une prochaine page...)
- ...
En fait ces facteurs pourraient influencer la probabilité de lancer une purge. Je vois bien une probabilité de ce genre:
- (1 - "période minimale entre deux purges" / (facteur1 * "temps écoulé depuis la dernière purge")) * (1 - "charge du serveur" / facteur2) * ("nombre de pages éditées au cours des derniers jours" / facteur3) * ...
Ensuite, après la sélection des pages à supprimer il ne reste plus qu'à vérifier combien il y en a, et ne pas le faire s'il y en a peu. --
LordFarquaad
Optimisation : purge conditionnée par la date de la dernière purge
Ce qui serait bien c'est de passer certains paramètres de configuration dans la base de données, comme ça on pourrait aussi vérifier d'abord la date de la dernière purge... --
LordFarquaad
Il y a deux possibilités en fait:
- Soit on ne fais jamais de purge si la période minimale entre deux purges n'est pas dépassée
- Soit on laisse ce facteur réduire la probabilité d'une purge dans la formule que je propose ci-dessus
--
LordFarquaad
On en revient encore et encore au même problème : la possibilité d'intégrer des données de configuration dans la base de manière souple. Et la encore, un stockage sous la forme de triplets (RDF ou éventuellement notre sauce (mais je préférerai RDF)) permettrai d'avoir une grande souplesse. Exemple pour résoudre ce présent problème (j'ai utilisé la notation N-Triples qui est très proche de ce qui serait stocké dans la base) :
<
http://www.wikini.net/wakka.php?wiki=CeWiki> <
http://wikini.net/vocabulaire/DernierePurge> "2005-01-15" .
--
CharlesNepote
Ah oui c'est sûr, ce serait une optimisation à faire une fois que cette décision sera prise, en attendant on peut se contenter de ne pas faire la requête de suppression s'il y a trop peu de pages à supprimer. Il faut voir le gain:
- Avantage:
- Une requête en moins (ça peut être considérable, quand on voit des logiciels comme PhpBB?? auxquels on reproche déjà de faire trop de requêtes, alors que de base il n'y en a que 10-15 par page... WikiNi c'est facilement 30-40 vu que c'est principalement proportionnel au nombre de liens internes de la page)
- Inconvénients
- Certaines pages peuvent rester longtemps sans être supprimées (est-ce si grave ? la purge sert à diminuer l'espace occupé par la bdd, or s'il y a peu de pages à supprimer, il y a peu d'espace à gagner... On pourrait éventuellement jouer sur l'espace occupé par les pages d'ailleurs (en mysql: l'utilisation de LENGTH sur le champ body devrait être une indication suffisante [à multiplier par deux tant que le champ body sera indexé...]))
- Le fait de supprimer des pages de la base de données diminue le nombre de résultats qu'il y aura au prochain SELECT effectué pour la purge. Dans le cas présent il est probable que la vitesse de cette requête dépende fortement du nombre de résultats potentiels (par "potentiel" je veux dire les pages qui sont antérieures à la date de purge et qui ne sont pas la dernière version, cela correspond à la première partie de la requête), donc si on ne supprime pas les pages à chaque coup; on alourdit les requêtes suivantes...
--
LordFarquaad