Qu'est-ce que Heartbeat ? Pourquoi il ralentit le backend de WordPress et fait monter en flèche le CPU

Apparaît dans le backend de WordPressUtilisation anormalement élevée de l'unité centrale, pics de requêtes dans le fichier admin-ajax.phpQuand, de nombreux webmasters se voient conseiller une phrase :

"LeEssayez de désactiver Heartbeat."

mais Qu'est-ce que le battement de cœur ??
Pourquoi cela ralentit-il l'arrière-plan ?
ilvraimentLes pics d'activité de l'unité centrale sont-ils en cause, ou sont-ils simplement mal placés ?boucs émissaires" ?

I. Qu'est-ce que le rythme cardiaque ? Une phrase explique ce qu'il fait

Rythme cardiaque est un ensemble d'éléments intégrés à WordPressMécanisme de battement de cœur en arrière-planL'essentiel est là :

Backend sans rafraîchir la page.Envoyer des requêtes AJAX au serveur à intervalles réguliersqui est utilisé pour synchroniser les états.

Ces demandes sont faites principalement par l'intermédiaire de la admin-ajax.php envoyé, la fréquence par défaut est :

• Toutes les 15 à 60 secondes
• Ouvrir la page d'arrière-plan ≠ inactif
• Tant que la page existe, Heartbeat "saute".

II. le rôle essentiel de Heartbeat (il n'est pas redondant)

La première réaction de nombreuses personnes est la suivante :

"Cette chose semble être un gaspillage de ressources".

Mais en réalité, Heartbeat prend en charge laMultiples fonctions clés du back-office.

Sauvegarde automatique

Lorsque vous écrivez des articles et modifiez des pages :

• WordPress enregistre régulièrement les brouillons
• Prévient les pannes de navigateur, les déconnexions et les fausses fermetures.

Ceci est une courtoisie de Heartbeat.

Verrouillage de l'édition (verrouillage du courrier)

Lorsque plusieurs personnes collaborent :

• A Articles en cours d'édition
• B Ouvrir le même article
• Le système indique : "Il est en cours de modification par un autre utilisateur".

De plus, Heartbeat est synchronisé.

Détection de l'état de connexion

Le rythme cardiaque sera confirmé périodiquement :

• L'identifiant est-il toujours valide ?
• Si vous devez revérifier les autorisations

Sinon, vous risquez de faire fonctionner un tas de choses en arrière-plan et de vous rendre compte que vous êtes "hors ligne" à la fin de la journée.

Plugins/thèmes avec fonctionnalité backend en temps réel

y compris, mais sans s'y limiter :

• Actualisation de l'état de la commande
• Plug-in de sécurité Contrôle des risques
• Calibrage en temps réel de l'éditeur

En particulier, l'utilisation de WooCommerce ce type de dépendance sera plus fréquent.

Pourquoi cela ralentit-il l'arrière-plan et fait-il grimper l'unité centrale ?

C'est là que le bât blesse :
Le rythme cardiaque en lui-même n'est pas lourd, c'est "ce qu'il déclenche" qui compte.

Le problème n'est pas de "sauter", mais de "faire beaucoup de choses à la fois".

chaque demande de Heartbeat :

1. entrer dans admin-ajax.php
2. Chargement du noyau de WordPress
3. Exécuter l'action montée / le crochet
4. "Interceptés et traités par les plug-ins

Si votre site remplit les conditions suivantes
Les pics d'utilisation du processeur peuvent se produire très facilement.

Les 5 vraies raisons de la montée en flèche des processeurs

Plusieurs onglets ouverts simultanément en arrière-plan

ceci estL'affection la plus courante mais la plus négligée: :

• Une page de backend = un Heartbeat
• 5 onglets = 5x demandes
• Plus plusieurs administrateurs en ligne en même temps

Les battements de cœur s'empilent directement.

Le plugin "fonctionne" sur Heartbeat

De nombreux plugins le font :

"Puisque Heartbeat se déclenche régulièrement, je vais vérifier quelque chose en attendant."

Par exemple :

• Plug-ins de sécuritéÉtat de la numérisation : État de la numérisation
• Plug-ins statistiquesLe journal : le journal de bord
• Plugin pour le centre commercialSynchronisation des ordres : Synchronisation des ordres
• éditeur (logiciel)Conservation des données structurelles

Le résultat :Un battement de cœur = plusieurs requêtes SQL complexes

admin-ajax.php lui-même est déjà un goulot d'étranglement pour les performances

Dans certains environnements de serveurs :

• admin-ajax.php La mise en cache n'est pas activée
• Nombre limité de processus PHP-FPM
• Réponse lente de la base de données

Heartbeat continue de frapper à la porte avec une puissance de traitement insuffisante.

L'éditeur backend lui-même est "lourd".

Lors de l'utilisation de l'éditeur de blocs, du constructeur de pages :

• Chaque battement de cœur est accompagné d'une comparaison de données.
• Structure JSON complexe
• Empilement automatique des révisions

L'utilisation du processeur augmente progressivement.

La configuration du serveur n'est pas adaptée au backend

Fréquemment trouvé :

• VPS à profil bas
• hébergement web
• Partage des ressources entre le back et le front office

Heartbeat amplifie les problèmes de performance existants.

V. Une erreur cognitive majeure : Heartbeat ≠ CPU Problem Source

C'est un point très important :

Le rythme cardiaque est un "déclencheur", pas un "fabricant".

C'est précisément ce qu'il fait :

• demande de signature temporelle
• fournir un point d'entrée unique

Ce qui consomme vraiment l'unité centrale est généralement :

• Fonctions montées sur le plugin
• Requêtes de base de données
• Ecriture du journal
• étalonnage de sécurité

Vous verrez donc un phénomène :

Idem pour Heartbeat.
R Le site est parfait.
B Site Direct CPU 100%.

VI. comment savoir si votre question a un rythme cardiaque ou non ?

Méthode de jugement rapide (pas de changement de configuration)

Vous pouvez observer ces trois signaux :

1. Si les pics d'utilisation de l'unité centrale ne se produisent qu'après l'ouverture d'une session dans le backend.
2. Fermer la page d'arrière-plan, l'unité centrale diminue-t-elle rapidement ?
3. Le fichier admin-ajax.php apparaît-il massivement dans les journaux du serveur ?

Si les trois sont vraies en même temps
Le rythme cardiaque est très probablement en cause.

Mais attention : participation ≠ coupable

La bonne question n'est pas :

"Dois-je désactiver Heartbeat ?"

Au lieu de cela :

"Que se passe-t-il vraiment lorsque Heartbeat est déclenché ?"

Pourquoi l'arrêt généralisé de Heartbeat est-il dangereux ?

De nombreux tutoriels le suggèrent directement :

"Désactiver Heartbeat en arrière-plan".

C'est le cas dans les scénarios suivantsHautement déconseillé: :

• Sites multi-auteurs
• Back Office du centre commercial
• Rédiger souvent des essais longs
• Utilisation de l'éditeur en ligne

Les conséquences possibles sont les suivantes :

• Échec de la sauvegarde automatique
• Modifier les conflits sans y être invité
• Statut de connexion anormal
• Risque croissant de perte de données

VIII. résumé des idées pour une bonne compréhension de ces questions

Vous devez vous souvenir de ces trois points :

1. Heartbeat, c'est de l'infrastructure, pas du code de pacotille
2. Les pics de CPU sont généralement dus à des problèmes de plugin/logique amplifiés par Heartbeat.
3. L'optimisation se concentre sur le "contrôle" et le "positionnement" plutôt que sur la "désactivation".

Conclusion : le rythme cardiaque n'est pas l'ennemi, c'est la perte de contrôle qui pose problème !

Si le backend de votre site ralentit et que l'unité centrale augmente :

• Ne désactivez pas d'abord Heartbeat.
• Comprenez d'abord que c'est enQuel est le déclencheur ?
• Décidez ensuite si vous devezLimiter la fréquence, limiter les pages, réduire la logique de montage

Une véritable optimisation professionnelle ne consiste jamais à "désactiver des fonctions".
Il s'agit plutôt de "laisser la fonction apparaître uniquement là où elle doit apparaître".

Contactez nous
Vous n'arrivez pas à lire le tutoriel ? Contactez-nous pour une réponse gratuite ! Aide gratuite pour les sites personnels et les sites de petites entreprises !	Service clientèle WeChat
① Tel : 020-2206-9892
② QQ咨询：1025174874
(iii) Courriel : info@361sale.com
④ Horaires de travail : du lundi au vendredi, de 9h30 à 18h30, jours fériés.