WordPress est mal codé ! (Créer un compte)

  • Statut : non résolu
15 sujets de 31 à 45 (sur un total de 62)
  • Auteur
    Messages
  • #585488
    quentin
    Membre
    Chevalier WordPress
    315 contributions

    dans l’absolu, je ne crois pas que le problème soit vraiment dans le media de stockage. Une table d’options, ca ne prend pas plus ou moins long à lire ou à écrire qu’un fichier de config. Certes il y a le parsing de la requete, mais ca c’est globalement des pouièmes, et la table a d’autres avantages (index déja monté en mémoire, fichier déja ouvert donc moins d’overhead etc.). Le problème n’est pas tant dans le mode de stockage que dans le mode de lecture. DAns l’état actuel des choses, si les infos étaient dans un fichier de config, wp irait lire ce fichier 10 (50 ?) fois par chargement de page, en allant un coup lire une ligne, puis une autre, puis relire la première etc.

    Le problème est dans la philosophie de l’accès aux données. WP exécute le script, et au fur et à mesure de son exécution, se dit « de quoi ai-je besoin ? ha, de cette option, allons la chercher », et se pose cette meme question virtuellement à l’intérieur de chaque fonction.
    A l’opposé, des scripts comme vbulletin, punbb & co, se demandent, au début du script, « de quoi vais-je avoir besoin au cours de l’exécution de ce script », ramnènent tout d’un coup, en profitant pour agréger des demandes variées faisant intervenir les memes tables dans une seule requete puis accèdent tout au long du script ces infos qui ont été lues une seule fois.

    #585489
    xavier
    Participant
    Maître WordPress
    2124 contributions

    Les dev WP ont expèrimenter avec la config en fichier, et vu les problèmes ont préféré se reposer sur MySQL…

    #585490
    Qwindoo
    Modérateur
    Maître WordPress
    2861 contributions

    Mais quels problèmes ? 😉

    Un fichier config.xml, une ligne au début du code : $config = simplexml_load(‘config.xml’); et le tour est joué 🙂

    Après, on accède aux variables en faisant $config->variable … pas plus simple ^^

    #585491
    xavier
    Participant
    Maître WordPress
    2124 contributions

    Pose la question sur wp-hackers 🙂
    http://lists.automattic.com/mailman/listinfo/wp-hackers

    #585492
    AmO
    Participant
    Maître WordPress
    4447 contributions

    Quentin : le blasé de WordPress :D

    #585493
    quentin
    Membre
    Chevalier WordPress
    315 contributions

    nan nan pas blasé 🙂. wordpress est exceptionnellement bien par plein d’aspects, je pense qu’on ne serait pas la sinon. Mais il est certainement perfectible, et ce genre de discussions permettent de partager ce que chacun juge le plus important de perfectionner 😉.

    #585494
    cdvddt
    Participant
    Initié WordPress
    9 contributions

    Les paremetres de configs dans la database , en plus d’etre un probleme de perfs, c’est avant tout un probleme fonctionnel.

    Pour moi, des parametres de type settings (preferences, parametres techniques, activation des plugins), ne sont pas du meme ordre que les « donnees » du blog.

    Typiquement, j’ai une version du blog en local, avec des posts de test sur lesquels je fais des essais de plugins, des hachs du theme etc.

    Ca me parraitrait plus correct de pouvoir tout uploader d’un coup sur mon serveur remote pour mettre a jour cette presentation / environement technique, sans avoir a aller reparametrer les plugins a la main (parce que les preferences sont enregistrées dans la DB).

    Je souhaite pouvoir desolidariser les donnees (une version de test/ une version de prod) et synchroniser mes parametres separement.

    Pour ca, WordPress utilise un paradygme qui va a l’oppose de ce qu’on voit d’ordinaire sur des applis CMS de ce type (fichier de config donnees dans une DB). Je vois pas pourquoi WP aurait un statut particulier ou des besoin particulier a cet egard.

    #585495
    quentin
    Membre
    Chevalier WordPress
    315 contributions

    en fait, prend un peu de recul, et regarde du point de vue WPMU. En tout logique, plus ca va aller, et plus wordpress devrait devenir un cas particulier de WPMU (un wordpress sera un WPMU avec un seul utilisateur) plutot que WPMU une extrapolation de wp comme c’est le cas aujourd’hui. Dans un tel contexte, les options du blog, deviennent les options d’un blog parmi d’autre, et du coup se rapprochent beaucoup plus de « préférences utilisateur » que de réel paramétrage. Dans ce contexte ca fait du sens de stocker les options dans une table (et encore une fois, je ne parierais pas que c’est plus lent).

    #585496
    artxtra
    Participant
    Chevalier WordPress
    149 contributions

    Mon hébergeur vient de fermer mon site pour, dit-il, trop de requêtes.
    Soit.
    Ca reste à vérifier.
    Mais puisque on est dans le débat, quelles seraient les requêtes à optimiser (WP2.0.4) ?

    #585497
    Qwindoo
    Modérateur
    Maître WordPress
    2861 contributions
    quentin wrote:
    Le problème est dans la philosophie de l’accès aux données. WP exécute le script, et au fur et à mesure de son exécution, se dit « de quoi ai-je besoin ? ha, de cette option, allons la chercher », et se pose cette meme question virtuellement à l’intérieur de chaque fonction (ce qui se traduit par une requête à chaque fois).

    A l’opposé, des scripts comme vbulletin, punbb & co, se demandent, au début du script, « de quoi vais-je avoir besoin au cours de l’exécution de ce script », ramnènent tout d’un coup (en une seule requête 😉 ), en profitant pour agréger des demandes variées faisant intervenir les memes tables dans une seule requete puis accèdent tout au long du script ces infos qui ont été lues une seule fois.

    Tout est dit : c’est un problème d’architecture, donc tes requêtes internes pourront être aussi optimisées que tu le veux, il y en aura toujours une par appel de fonction 😕

    #585498
    Qwindoo
    Modérateur
    Maître WordPress
    2861 contributions

    Beuh ?! où qu’il est passé le dernier post d’AmO ?

    #585499
    AmO
    Participant
    Maître WordPress
    4447 contributions

    Je me suis auto censuré 🙂

    Je vais faire des tests pour vérifier mes dires… c’est ajouté dans ma todolist (page 6, ligne 896)

    #585500
    matthieu
    Membre
    Chevalier WordPress
    296 contributions

    (page 6, ligne 896)

    over booké ce Amo, c’est ça les stars 🙂

    #585501
    LH
    Membre
    Chevalier WordPress
    372 contributions
    MS-DOS_1991 wrote:
    quentin wrote:
    Le problème est dans la philosophie de l’accès aux données. WP exécute le script, et au fur et à mesure de son exécution, se dit « de quoi ai-je besoin ? ha, de cette option, allons la chercher », et se pose cette meme question virtuellement à l’intérieur de chaque fonction (ce qui se traduit par une requête à chaque fois).

    A l’opposé, des scripts comme vbulletin, punbb & co, se demandent, au début du script, « de quoi vais-je avoir besoin au cours de l’exécution de ce script », ramnènent tout d’un coup (en une seule requête 😉 ), en profitant pour agréger des demandes variées faisant intervenir les memes tables dans une seule requete puis accèdent tout au long du script ces infos qui ont été lues une seule fois.

    Tout est dit : c’est un problème d’architecture, donc tes requêtes internes pourront être aussi optimisées que tu le veux, il y en aura toujours une par appel de fonction 😕

    Salut,

    Sous WP2.0.5, il y a un système de cache:
    La fonction bloginfo charge les données SQL dans un cache. Il n’y devrait donc pas avoir de requête SQL à chaque fois… Enfin si ce cache fonctionne correctement.
    De ce que j’ai regardé, ce cache utilise un … fichier !
    Peut-être que ça va réconcilier un peu tout le monde ?

    Ceci dit, s’il y a des problèmes de performances, il reste à trouver d’où ça vient vraiment.
    Est-ce que vous avez des chiffres ? comme le nombre de requêtes, le temps de réponse pour vos blogs, histoire d’avoir une idée plus précise.

    Mon idée sur la lenteur de WordPress est que ça doit venir pour une bonne partie des apply_filter.
    L’application passe son temps à faire des copies de chaînes de caractères pour un éventuel traitement…

    #585457
    quentin
    Membre
    Chevalier WordPress
    315 contributions

    a propos des apply_filter, il existe une page qui explique comment ca marche ? J’ai po compris et j’ai rien trouvé dans le codex. Quand je tombe dessus dans le code je me demande toujours quelle tambouille ca déclenche.

15 sujets de 31 à 45 (sur un total de 62)
  • Vous devez être connecté pour répondre à ce sujet.