Wikini

OptimisationWikiniEtudeCode

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-3-80-129-195.compute-1.amazonaws.com

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:



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) :



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



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)


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:


En fait ces facteurs pourraient influencer la probabilité de lancer une purge. Je vois bien une probabilité de ce genre:


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:


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


-- LordFarquaad
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]