Wikini

OptimisationWikiniTest

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-3-133-141-6.us-east-2.compute.amazonaws.com

Rapport des tests en vue de l'Etude pour l'optimisation de Wikini



Ressources pour l'optimisation











Afin d'évaluer les gains : système de statistiques


Je suis sur le fait qu'il faut établir un système pour mesurer les temps d'exécution. Je propose même d'aller plus loin en développant un système qui créé des statistiques sur les temps d'exécutions. Cela coutera un peu mais ça permettra de mieux se rendre compte.
-- PatrickPaul

Il nous faut un moyen d'évaluer les gains. Que valent les informations de débogage mise en place par l'auteur ? Je crois me rappeler pour les avoir vues, qu'elles ne concernent que les requêtes SQL. -- CharlesNepote

Avant que PatrickPaul ne lance son éditeur plus vite que son nombre ;-), je propose les idées suivantes.
Par expérience, tous les systèmes de statistiques qui sont codés dans une applications sont voués à l'échec et à de permanentes transformations : il y a toujours un utilisateur qui veut une chose que l'on a pas réalisé... "et pourquoi pas le ratio des "referrers" par mois et par pays" (je suis persuadé qu'il y a un gus qui va avoir ce besoin...).
Il y a donc une solution simplissime à ce problème : fournir des informations brutes au format CSV. De cette manière, l'utilisateur à tout loisir à traiter ces données comme il le souhaite, a posteriori, à l'aide de son outil statistique favori : OpenOffice, Excell, CristalReport?, etc. La richesse des traitements est donc déplacée dans les outils spécialisés et non dans l'application dont ce n'est pas le "coeur de métier". Ca n'empêchera d'ailleurs pas certains utilisateurs de créer des "actions" allant puiser dans ces données brutes.
Par ailleurs, les statistiques peuvent servir à autre chose qu'à évaluer les performances : il faut prendre le problème globalement.
Il nous faut donc déterminer maintenant (je vous laisse compléter) :

-- CharlesNepote


Mesure du temps de traitement


Avant les importants changements opérés par l'internationalisation et autres, je suggère d'améliorer la mesure du temps de traitement en démarrant le "chronométrage" en tout début de traitement (soit au début de wakka.php) et en le terminant en toute fin de traitement (c'est-à-dire à la fin de footer.php). Cela nous permettra de mesurer les écarts après la modification des divers éléments. En local chez moi, j'ai personnalisé WakkaFr afin d'obtenir une mesure du temps global de traitement de chaque page affichée.
Pour cela, j'ai :
J'obtiens ainsi un résultat arrondit à la quatrième décimale (par exemple : 0.1532). Au passage j'observe chez moi en local des résultats oscillant entre 0.1 et 0.7 sur une machine pas trop chargée avec 256 Mo et un pentium III à 660 Mhz. Le code ci-dessus peut peut-être être amélioré...
Je propose que cette mesure soit systématiquement présente dans le source html à destination du client qui a demandé une page :
Il est cependant probable que la présence systématique de cette mesure empêche l'utilisation du cache (je ne comprend toujours pas bien comment fonctionne le cache). Aussi il serait peut-être plus intéressant de proposer cette mesure comme une option (configurable à travers le fichier de configuration).
Qu'en pensez-vous ?
-- CharlesNepote
une case à cocher de plus dans les préférences ? ou simplement par un bouton qualque part avec un cookie pour afficher le temp d'execution (comme ça par defaut c'est désactivé, et cela ne risque pas d'affecter le travail sur le cache) --Err404?


A mon avis, on peut d'ores et déjà mettre en place la mesure proposée par CharlesNepote. Pourquoi ne pas ajouter l'affichage, pour l'instant, dans le paragraphe debug existant de footer.php ?
-- DavidDelon

D'accord avec Patrick et David. Reste deux questions en suspend :
  1. Comment afficher le temps total d'exécution que j'ai proposé :
    1. dans le groupe de mots (<span>) de style intra paragraphe "debug" existant, affiché en fonction du paramètre "debug"
    2. dans un groupe de mots (<span>) de style intra paragraphe "debug" à part, affiché en fonction du paramètre "debug"
    3. dans un groupe de mots (<span>) de style intra paragraphe "debug" à part, affiché en fonction du paramètre "print_time"
    4. dans un paragraphe (<div>) de style "p_debug", affiché en fonction du paramètre "debug" (Pour : on peut placer le paragraphe n'importe où (par exemple en haut à gauche) uniquement en modifiant la feuille de style)
    5. dans un paragraphe (<div>) de style "p_debug", affiché en fonction du paramètre "print_time"
  2. Quels sont les fonctions proposées par le système de statistiques évoqué par Patrick ? (je vous laisse remplir un peu ;-)

Pour la question 1 je penche plutôt pour la solution 5 car je pense qu'il y a des administrateurs techniques ou fonctionnels qui seraient désireux de voir systématiquement le temps d'exécution de la page sans avoir toutes les informations de débogage (par exemple ici sur WakkaFr où il me paraît intéressant d'avoir systématiquement cette information (pour cause d'observation du comportement des nouvelles versions) sans avoir néanmoins les informations de débogage). -- CharlesNepote OK -- DavidDelon

Bon j'ai choisi finalement l'option 1. On verra ensuite pour la 5...
J'ai ajouté en plus : l'arrondi à la 4ème décimale de toutes les mesures ; le temps total des requêtes SQL ; le % de requêtes SQL sur le temps total (au passage, chez moi j'obtien entre 15 et 30 % max). On verra le code ci-dessous de /actions/footer.php. Mais je ne peux plus rien publier sur le CVS !...
Est-ce que vous voyez d'autres données statistiques que l'on pourrait intégrer facilement ?
-- CharlesNepote
<?php

    if ($this->GetConfigValue("debug"))
    {
        print "<span class=\"debug\"><b>Query log :</b><br />\n";
        foreach ($this->queryLog as $query)
        {
            print $query["query"]." (".round($query["time"], 4)." s)<br />\n";
            $t_SQL = $t_SQL + $query["time"];
        }
        print "</span>\n";
        
        print "<span class=\"debug\">".round($t_SQL, 4)." s (total SQL time)</span><br />\n";
        
        list($g2_usec, $g2_sec) = explode(" ",microtime());
        define ("t_end", (float)$g2_usec + (float)$g2_sec);
        print "<span class=\"debug\"><b>".round(t_end-t_start, 4)." s (total time)</b></span><br />\n";

        print "<span class=\"debug\">SQL time represent : ".round((($t_SQL/(t_end-t_start))*100),2)."% of total time</span>\n";
    }

?>


En cherchant du côté des profiler pour php j'ai trouvé ceci : dbg qui est un debugger + profiler. Très facile à installer, on peut s'en servir juste pour la mesure des temps d'execution en suivant l'exemple Sample of using dbg/profiler API in PHP à télécharger sur le site de dbg (partie download).
Pour avoir une idée de ce que ça donne, voici quelques lignes de résultat (voir ci-après) . Yapluka analyser tout ça ...

Et ca donne ceci (je n'ai gardé que les 10 fonctions les plus consommatrices de temps), sur une page
standard, sans appel d'action, du type page principale.

- wakka.php, wiki:loadpage, 7,291ms, 16 appels
- wakka.php, wiki::href, 8,074ms, 20 appels
- actions.footer,php, ::main, 8,155ms, 18 appels
- wakka.php, wiki::loadall, 10,361ms, 16 appels
- wakka.php, ::main, 10,426ms, 1 appels
- wakka.php, wiki::link, 12,500ms, 15 appels
- wakka.php, wiki::getmicrotime, 30,067ms, 37 appels
- formatters/wakka.php, wakka2callback, 76,977ms, 24 appels
- wakka.php, wiki::query, 105,612ms, 18 appels
- wakka.php, wiki::includebuffered, 184,813ms, 7 appels

Total (toutes fonctions) :615,705

Pour une page de test compléte voir : http://stephane.aulery.free.fr/wikini/wikini_test_de_performance1.htm

Sans surprise, les query consomment beaucoup, mais, surprise, les includebuffered également (c'est juste
le "include" qui est comptabilisé; ce temps d'inclusion n'étant pas constant, je suppose qu'il est fonction de la taille du
fichier inclus ...
Certes la structure de l'application est trés modulaire mais ça se paie donc quelque part ...

A noter au passage : le temps consommé par getmicrotime !

Une petite erreur d'analyse : j'ai fait ces tests sur un wakka sans la lecture du fichier interwiki. avec la lecture de interwiki
on peut rajouter en moyenne 50 ms. Je propose de supprimer ce fichier de l'application, son interêt ne me parait pas franchement évident.

-- DavidDelon

Bravo David pour cette analyse. Mes questions/réflexions un peu dans le désordre.

Les problèmes de performances que nous avons ne sont donc pas côté applicatif. On peut donc, par exemple, se demander si on a bien gagné d'externaliser la feuille de style : en théorie oui parce qu'on utilise le cache du navigateur, mais en pratique, il faut une requête réseau supplémentaire pour être sûr que la page n'a pas changé. Ce qu'il faut donc voir c'est étudier si l'on peut .

-- CharlesNepote


WakkaFr ça rame le soir et le week-end (sur free en tous cas)


Alors voila, moi mon Wakka fonctionne sur Free, comme ton site David, et y'a des heures où ça rame à mort... et ça vient des la base de données MySQL. Je veux proposer une projet "WakkaFr=>HTML" qui permettrait de créer de façon automatique une version html de toutes le pages, pour que les visiteurs puissent tout le temps bénéficier d'une bonne vitesse d'accès au site au moins en lecture.

Qu'en dites-vous ? Personnellement je pense pas que ça soit trop difficile à mettre en oeuvre. -- PatrickPaul

C'est vrai que ça rame, si ça devient trop pénible il y a peut etre moyen de transferer tout ça vers une autre machine ... D'un autre côté, ça nous "oblige" à faire du performant !
Sinon pour ton idée : c'est bien de "cache" dont tu veux parler ? Pas de problème, d'ailleurs l'auteur de wakka en parle dans son site, à mon avis c'est pas si simple, il faut bien
veiller par exemple à regenerer une page cachée faisant référence a une page en attente de création (une wantedpage) lors de la création de cette page.
-- DavidDelon






(Oui : le temps de resolution DNS, la latence (temps de reaction materiel reseau), le debit disponible, la charge de la machine serveur (la prise en charge de la requête par le serveur ne sera pas immédiate) ... -- DavidDelon )




Patrick, avant toute modification importante de wakka pour mettre en place les caches, j'aimerais que toi non plus tu ne t'emballes pas
avec une solution qui risque de bouleverser totalement la structure de l'application, aussi je te demande de ne pas modifier le CVS pour tout
ce qui est cache mais de nous montrer ce que ca donne sur ton site sur free avant, comme CharlesNepote et moi-même l'avont fait pour l'internationalisation ou sur d'autres sujets.
-- DavidDelon






Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]
2011-09-07 23:10:04 :: Propriétaire : WikiAdmin :: Rétro-liens :: Cartographie :: Recherche :
XHTML 1.0 valide ? :: CSS valide ? :: -- Fonctionne avec WikiNi 0.5.0 (interwiki)