web-dev-qa-db-fra.com

Comment diagnostiquer un administrateur Wordpress lent?

Au cours des derniers mois, le chargement des pages d’administration de mon site multisite wordpress (environ 80 sites) a pris environ 20 secondes. J'utilise la dernière version de wordpress (version 4.1).

Lorsque j'ai renommé le dossier des plugins en "plugins-désactivé", la zone d'administration est revenue à une vitesse normale de trois secondes. Cependant, lorsque j'ai renommé le dossier "plugins", le site a repris ses 20 temps de chargement habituels. J'ai ensuite désactivé tous les plugins et la zone d'administration est restée à sa vitesse lente habituelle, même si les plugins ont été désactivés.

J'ai supprimé tous les plugins et les ai téléchargés un par un - l'administrateur a ralenti avec chaque plugin supplémentaire, quel que soit le plugin que j'ai téléchargé. La conclusion évidente à tirer est que Wordpress charge chaque plugin, qu'il soit activé ou non.

Ma question - comment puis-je valider cette hypothèse, et aussi, comment puis-je diagnostiquer davantage le problème?

Quelques autres faits

  1. Le site est un multisite wordpress avec environ 80 sites
  2. Il fonctionne sur Windows Azure
  3. Le problème a commencé au cours des derniers mois
  4. Tous les plugins sont activés
  5. J'exécute le plugin de moniteur de requête
  6. L'installation a environ huit ans

Comment puis-je trouver d'où vient la lenteur?

Mise à jour 1: J'ai utilisé les outils de développement Chrome - et environ 95% de la vitesse de chargement se trouve dans la demande Get initiale - ce qui semblerait suggérer que le problème se produit sur le serveur, pas l'un des éléments de charge auxiliaire

Update 2: La simple présence du plugin Gravity Forms semble ajouter environ 9 secondes au temps de chargement du site. Cela se produit lorsque le plugin est désactivé.

Update 3: J'ai optimisé la base de données sans aucun effet.

multisitewp-adminwindows
5
Steve French

Le problème semble être dans la version de WordPress - en particulier WordPress 4.1 lors de l'exécution de MultiSite - j'ai rétrogradé à 4.0.1 et tous les problèmes ont disparu.

0
Steve French

Je ne peux pas parler à tous les plugins qui chargent, même s'ils sont désactivés, mais les formulaires par gravité ne sont pas conçus pour un usage intensif et pourraient bien contribuer de manière significative au problème.

J'avais l'habitude de travailler avec un gros client qui utilisait des formulaires à gravité et leurs panneaux d'administration (et leur soumission) devenaient si lents qu'ils finissaient par commencer à fonctionner complètement.

Je n'ai plus les détails qui traînent, mais le problème avec les formulaires à gravité à l'époque était que lorsqu'un formulaire est soumis, les formulaires à gravité ont les effets suivants:

  • Charge chaque formulaire qui a déjà été soumis
  • Parcourt chacun d’eux jusqu’à la fin
  • Utilise la dernière entrée soumise et en ajoute une pour générer le prochain identifiant unique

À l'époque, j'ai créé un correctif pour le client, je l'ai testé, appliqué et soumis à des formulaires gravimétriques ... et je n'ai jamais eu de réponse. Les quelques fois suivants, le client a mis à niveau les formulaires de gravité, le problème était identique et je devais réappliquer le correctif. Je les ai finalement réussi à changer de service.

Si vous utilisez un grand nombre de plugins qui ajoutent des colonnes supplémentaires aux panneaux d’administration de wordpress (par exemple, les messages de liste, les pages de liste, etc.), je suppose que cela fait au moins partie du problème, c’est que la plupart des auteurs de plugins utilisent des requêtes pour: chaque élément du système pour modifier la liste plutôt que de modifier la requête d'administration appropriée afin d'inclure ce qu'ils cherchent dans les résultats de publication.

GRANDS AVERTISSEMENTS

  • Si vous n'êtes pas complètement à l'aise avec php, n'essayez pas cela .
  • Dans la mesure du possible, faites ceci en premier sur un serveur de transfert pour vous assurer de ne pas casser quelque chose
  • Assurez-vous absolument de sauvegarder tous les fichiers que vous allez éditer avant de les éditer ... afin de pouvoir les remettre rapidement au besoin

Ceci étant dit, la seule chose à laquelle je pourrais penser qui pourrait aider serait de termporarily pirater le noyau wordpress comme suit:

(si exécuté 4.1):

Activer le journal de débogage et désactiver l'affichage public des erreurs (wp-config.php):

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Cela créera un fichier journal de débogage dans votre répertoire de thème.

éditez le fichier wp-settings.php et recherchez ce qui suit aux lignes 213 à 216:

foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
   wp_register_plugin_realpath( $plugin );
   include_once( $plugin );
}

remplacez-le par le suivant:

foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
   wp_register_plugin_realpath( $plugin );
   $start_at = time();
   if ( WP_DEBUG_LOG ) {
      error_log("Loading plugin {$plugin}\r\n\t Start: {$start_at}");
   }
   include_once( $plugin );
   $end_at = time();
   if ( WP_DEBUG_LOG ) {
      error_log("\t Finished: {$end_at}");
      error_log("\t Total Time: " . $end_at - $start_at . '(s)' );
   }
}

Cela ne vous dira que si un plugin fait quelque chose de mal lors de son premier chargement.

Vous pouvez faire temporairement la même chose avec la commande do_action ('plugins_loaded') trouvée dans le même fichier à la ligne 237, mais cela ne vous indiquerait que le temps nécessaire au chargement de tous les plugins.

Pour indiquer le temps que chacun prend, vous pouvez vous connecter à plugins_loaded avec la priorité 1, lire tous les points d'ancrage de plugins_loaded, les mettre à jour pour qu'ils aient des priorités différentes, puis ajouter votre propre action de plugins chargés pour enregistrer l'horodatage entre chaque intervalle.

par exemple.

configurez tous les plugins de manière à ce que le premier à l'aide des plugins soit chargé à 10h, le second à 12h, etc ..., puis ajoutez votre propre action plugins_loaded entre chacun pour enregistrer l'heure et éventuellement l'heure prise à chaque étape:

9: a commencé

11: 1 seconde (horodatage nnnnnnnnnn)

13: 0 secondes (horodatage nnnnnnn)

15: 8 secondes (horodatage nnnnnn)

Je sais que ce n'est probablement pas une tonne d'aide, mais cela pourrait au moins vous laisser savoir quel est le coupable.

En utilisant les commandes de débogage ci-dessus, vous pouvez avec précaution apporter des modifications temporaires aux fichiers wordpress principaux pour consigner la durée sans laquelle des plugins défectueux plantent le site en affichant des erreurs au début du processus.

9
Privateer

Connaissez-vous la barre de débogage ? Si vous l'ajoutez et que vous activez SAVEQUERIES, vous pouvez voir le temps nécessaire à chaque requête.

define( 'SAVEQUERIES', true );

Ensuite, vous pouvez ajouter davantage de plug-ins de barre de débogage pour profiler d'autres éléments, tels que Requêtes à distance de la barre de débogage pour les demandes distantes et Actions lentes de la barre de débogage pour profiler les points d'ancrage WordPress.

La plupart du temps, vous pouvez facilement trouver un goulot d'étranglement, concentrez-vous sur le plus gros en premier. Essayez d'isoler d'où il vient.

Lorsque vous ne trouvez pas le goulot d'étranglement à l'aide de cette méthode, il est temps de plonger dans le profilage de PHP, mais c'est presque impossible sans l'expérience de PHP.

0
Anton Timmermans

D'après mon expérience, si vous allez déplacer votre site de Windows vers Apache Web Server, vous obtiendrez une augmentation de vitesse d'environ 40%, car Apache est plus efficace pour les applications Php telles que WordPress.

Néanmoins, si vous n’avez pas le choix de revenir en arrière, vous devez essayer 10 façons d’améliorer les performances de WordPress sous Windows .

Aussi, je suggérerais d'utiliser P3 (Plugin Performance Profiler) pour analyser le temps de chargement de chaque plugin.

0
Mohammad Mursaleen