- Statut : non résolu
- Ce sujet contient 61 réponses, 14 participants et a été mis à jour pour la dernière fois par
, le il y a 16 années et 8 mois.
-
Messages
-
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.Les dev WP ont expèrimenter avec la config en fichier, et vu les problèmes ont préféré se reposer sur MySQL…
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 ^^
Pose la question sur wp-hackers 🙂
http://lists.automattic.com/mailman/listinfo/wp-hackersnan 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 😉.
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.
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).
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) ?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 😕
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)
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…
- Vous devez être connecté pour répondre à ce sujet.