Refactoring Wordpress pour améliorer les performances de la mémoire [fermé]

J'ai examiné de près la consommation de mémoire Wordpress. Sur mon site, il semble que pour chaque page consultée, 20 Mo de RAM soient alloués, histoire de préparer un environnement confortable pour l'exécution de tous les plug-ins. Je l'ai tracé ainsi:

Il n'y a pas de point unique à optimiser, pas de méchant qui mange la plus grande partie de la mémoire. La consommation est répartie sur de nombreux modules php.

Comment faire en sorte que Wordpress initialise son environnement en mémoire une seule fois, puis le réutilise plusieurs fois pour chaque résultat? Je ne veux pas que PHP lent consomme 20 Mo à chaque clic d'utilisateur - même sur un serveur avec beaucoup de mémoire, il faut quelques secondes pour que tout ce travail soit effectué. Vous auriez essentiellement besoin de morceaux de mémoire en lecture seule pouvant être réutilisés.

Aussi ... pourquoi 20MB? Quelqu'un peut-il donner un aperçu de cela?

Edit: Voici la sortie WinCacheGrind sur le Wordpress en cours d’exécution sur ma machine de développement (beaucoup plus rapide que l’hébergement partagé). Comme vous pouvez le constater, il faut une seconde de travail pour produire le code HTML de la page principale. Ralentissez en hébergeant un hébergement partagé et vous aurez la recette du problème. J'ai choisi la méthode qui prend le plus de temps. Comment vous y prendriez-vous pour l'optimiser?

Edit: Voici les statistiques de requête de cet outil de profiling functions.php fantastique .

Chargement: 12 requêtes - 532ms - 19.1MB - 43 résultats de cache / 53
Requête: 15 requêtes - 563ms - 19.0Mo - 72 résultats de cache / 86
Afficher: 21 requêtes - 705ms - 19.2Mo - 234 résultats de cache / 257

Edit: Voulez-vous voir quelque chose qui va vous faire paniquer? Insérer ces lignes à la fin de index.php:

echo "<pre>\n";
print_r(get_defined_vars());
echo "</pre>\n";

J'ai essayé de compter combien de fois le corps de la publication actuelle est enregistré dans la mémoire. J'ai compté 20 instances. Ensuite, j'ai réalisé que PHP avait un comptage de références, alors le nombre de copies a été réduit à trois: deux semblent être dans WP_Query, un dans le cache d'objets. J'enquête plus loin.

C'est pourquoi je pense que WordPress a besoin d'un refactoring ciblant les problèmes de mémoire. Vous ne pouvez plus imputer sa consommation de mémoire à la complexité de son travail. Il fait simplement un tas de choses fausses .

Edit: Après une journée passée à essayer de comprendre cela, voici mes conclusions:

1) 88% de la mémoire totale provient d'appels de type require, include ou include_once:

2) Les fichiers php inclus se produisent principalement pendant la première partie du traitement d'une requête (ce qui n'est pas surprenant), c'est également l'endroit où toute la mémoire est consommée:

3) Il est assez intéressant de tracer toutes les fonctions en cours d'exécution lors d'une requête. Il y a plus de 12 000 appels au total. Je les ai secoués pour les rendre plus visibles (l'axe Level est essentiellement la profondeur de l'empilement):

4) Le seul moyen d'avancer auquel je puisse penser est de minimiser le nombre de fichiers .php inclus. Si je divise les fonctions par fichier, vous pouvez voir que de nombreux fichiers sont consultés une ou deux fois au plus. Nous avons besoin d'un moyen de les éviter quand ils ne sont pas nécessaires. Par exemple, mon plug-in de sauvegarde de base de données distante est chargé et enregistré, juste pour ne jamais être utilisé du tout. Voici le tracé ci-dessus divisé par nom de fichier:

J'offre une prime qui vaut toute ma réputation :) pour des modifications qui conduiraient à une réduction de 30% ou plus de la mémoire de mes blogs.

Edit: J'ai installé WP 3.1, voici une comparaison avec l'ancienne version.

Le bleu est WP 3.1, le rouge est 3.0.4. Le nouveau WP est plus rapide, mais consomme également plus de mémoire.

Voici une liste par fichier d'inclusion.

Cela me permet de réaliser à quel point "All In One SEO Pack" consomme de la mémoire - une solution serait d'utiliser une fraction des fonctionnalités du plugin pour obtenir ce que je veux. En outre, mes propres plugins semblent être assez mauvais.

Je voudrais essayer le chargement conditionnel, par exemple, comment.php (j'autorise les commentaires sur mon blog) et plusieurs autres. J'ai supprimé tout le code obsolète. J'ai réduit kses.php pour ne charger que ses tables globales à la demande. J'ai simplifié l10n (je ne fais pas de localisation), rendant ses fonctions renvoyer les chaînes immédiatement, sans recherches. Je suis encore loin des 30% que j'ai arbitrairement établis.

Edit: J'ai téléchargé et activé APC avec les paramètres par défaut (32 Mo de cache opcode). Voici la comparaison:

Vous pouvez voir que le chargement du code s’est considérablement accéléré et que le code prend moins de place en mémoire (probablement parce que nous ne traitons que des opcodes, pas de la source originale). La consommation de mémoire est cependant encore assez élevée.

Ne vaut pas la peine. WordPress ne consomme pas beaucoup de mémoire simplement parce que. Il consomme beaucoup de mémoire car il exécute beaucoup de fonctionnalités sous le capot.

Il est beaucoup plus facile et efficace de mettre en cache les résultats (page générée) avec le plugin cache statique et de les diffuser. De cette façon, la plupart des visiteurs ne toucheront même pas WP.

Et c’est la raison pour laquelle je pense que WordPress a sérieusement besoin d’une réécriture. Vous ne pouvez plus imputer sa consommation de mémoire à la complexité de son travail. Il fait simplement les choses mal.

Quelle conclusion naïve. Lisez des choses que vous ne devriez jamais faire, première partie .

Merci pour les parcelles d'utilisation de la mémoire, cependant.

Beaucoup plus tard, Edit : Autommatic a publié une bibliothèque appelée prefork qui semble faire ce que vous demandez: charger le code WordPress dans la RAM une seule fois.

À partir de WordPress 3.2, PHP 5.2 sera la configuration minimale requise. Je pense qu'avec ce qui se passe sous notre ceinture, des fragments du noyau peuvent commencer à être restructurés et à utiliser des classes avec chargement automatique. Cela nous éviterait de charger des morceaux de code, à moins qu'ils ne soient réellement nécessaires. Par exemple, s'il n'y a pas d'intégration ou de galerie dans une page, nous pourrions peut-être éviter de charger une grande partie du code multimédia.

Cependant, même s'ils décidaient de suivre cette voie, je m'attendrais à ce que ce soit une lente évolution (comme la plupart des autres changements imprévus qui se sont produits). Cela nécessiterait de mélanger l'emplacement de beaucoup de fichiers et de codes, ce qui risquerait de faire basculer la compatibilité en arrière pour certains plug-ins.

Une partie du problème (si on peut vraiment l'appeler ainsi) réside dans le fait que sans ce type de chargement conditionnel, le cadre de base ne peut pas savoir à l'avance quelle fonctionnalité il aura besoin ou non pour générer l'affichage du contenu. Donc, beaucoup de fonctions doivent être chargées au cas où elles seraient nécessaires.

Comment faire en sorte que Wordpress initialise son environnement en mémoire une seule fois, puis le réutilise plusieurs fois pour chaque résultat?

C'est ce qu'on appelle la mise en cache opcode.

http://en.wikipedia.org/wiki/PHP_accelerator

vous ne réussirez probablement pas à réduire autant l’utilisation de la RAM. Mais si vous utilisez mod_php, vous voudrez peut-être passer à la mod_fcgidplace.

Bien que mod_php soit légèrement plus lent, il charge php même s'il n'en a pas besoin, par exemple pour servir des images, des fichiers statiques ou même la mise en cache. Si vous avez beaucoup de demandes, c'est beaucoup de bélier.

utiliser fcgid réduira beaucoup cela.

de plus, l'utilisation d'un cache statique (comme le cache w3total) évitera l'appel de php, ce qui est un avantage considérable: moins d'utilisation de RAM, moins de connexions à la base de données.

Ha. Je travaille sur une application web maintenant que je ferme intention de surcharger les données et l' utilisation au - delà de ce que mon compte d' hébergement mutualisé peut gérer, alors j'ai décidé - alors qu'il aurait été super facile à construire dans WP - pour essayer de travailler à partir BackPress comme un cadre et construisez seulement ce dont j'avais besoin pour mes cas d'utilisation spécifiques.

Ainsi, j'ai pu réduire mon environnement principal des centaines de fichiers PHP dans WP à une vingtaine environ de mes besoins réels, tout en pouvant exploiter toutes les bases de données, HTTP, gestion des utilisateurs, formatage et cron. fonctions que j'aime dans WordPress.

Le problème est que cela demande beaucoup de travail et que je ne ferais jamais confiance à mon travail pour rien au-delà de mon usage personnel. Si vous souhaitez utiliser l’environnement WP complet, tenez-le tel quel. C'est aussi bon que cela grâce à des centaines de développeurs qui l'ont peaufiné au cours de plusieurs années. Comme tout le monde l’a dit, vous irez beaucoup plus loin en trouvant un meilleur plan d’hébergement et en recherchant des techniques de mise en cache que vous ne le ferez probablement en piratant le noyau.

Oui, WordPress charge tout en premier, puis fait ce que nous lui demandons de faire. Je peux rappeler quelque part que nous pouvons créer un pool virtuel dans la RAM où nous pouvons mettre des fichiers. J'ai eu l'idée de mettre tout le WordPress en mémoire (<10 Mo) et nous pourrions économiser beaucoup d'E / S, ce qui seul devrait donner un coup d'accélérateur. Mais je n'ai jamais eu la chance de l'essayer et de plus, je ne suis pas vraiment compétent dans la poursuite de ce genre de chose. Mais ça a l'air d'essayer.

quelques suggestions de base:

1. w3 total cache plugin pour la mise en cache ..
2. obtenez memcache installé et activé, activez également à partir des paramètres de cache total de w3 (le cache opcode est une bonne option aussi, mais cela ne se passe pas bien avec le plugin de cache total de w3)
3. minimiser les requêtes pour diriger les liens dans les fichiers de thème.
4. Désactivez tous les plugins inutilisés et supprimez-les.
5. optimiser la base de données.

Je gère un site wordpress bien connu avec un trafic énorme tous les jours .. je ne suis pas sur dédié même, faisant très bien pour moi :)