Cet article est plutôt issu d'une série de «notes d'hôtesse». Eh bien, un peu plus sur les expériences personnelles et le gougeage.
Si vous devez gérer des sites WordPress sur lesquels le plug-in de mise en cache WP Super Cache est installé, l'article peut vous être utile. Sinon, ce n'est qu'une courte histoire.
Bref, le début de l'histoire est le suivant: il y avait un site. Nouvelles et informations thématiques. Fabriqué par un assistant inconnu sur CMS WordPress. Et fait exactement ce qui était permis à ce moment-là par le biais de son propriétaire. Au fil du temps, le site a gagné en popularité, le nombre de visiteurs a augmenté. Le site lui-même a "gagné" sur la publicité. C'est-à-dire plus il y a de visiteurs, mieux c'est. À un moment donné, lors des pics de charge, le site a commencé à se plier: des pages chargées lentement et tout ça. Mais, bien sûr, jusqu'à ce que le coq picore, personne ne bougeait vraiment. Le coq est apparu au moment où le site était censé couvrir un événement qui a attiré l'attention du public. Les visiteurs se sont précipités, le site est tombé en panne et tous les revenus estimés fondaient sous nos yeux. En raison des circonstances, j'ai dû agir comme réanimateur. J'ai alors écrit
un article à ce sujet. Ma décision était effrayante (ne répétez pas), mais l'objectif principal a été atteint - les rêves ont été enregistrés. Surtout.
Bien sûr, personne n'était intéressé à répéter une situation similaire et a travaillé sur le site. Tout d'abord, ils ont découvert les raisons de la chute et de la forte charge sur le serveur. Ils étaient monnaie courante: l'absence d'un site de mise en cache en tant que tel et un mécanisme mal implémenté pour enregistrer et afficher le nombre de vues d'articles. Ce dernier a lui-même créé une charge décente: à chaque demande de page d'article, il a extrait de la base de données le nombre de vues de cet article, l'affichait, puis en ajoutait une et la réécrivait dans la base de données. Dans le même temps, la table
wp_postmeta avec métadonnées a été utilisée pour le stockage (comme elle semble être appelée dans WP). Dans lequel la masse était stockée sans rapport avec les vues comptables de l'information et qui était très importante.
Le problème de mise en cache a été résolu simplement: dans un environnement calme, le plugin WP Super Cache a été installé normalement. Ce que beaucoup, si je me souviens bien, m'a conseillé de faire à la place de la béquille étrange que j'ai construite dans les commentaires sur cet article. Honnêtement, j'ai alors et maintenant mal navigué dans l'écosystème WordPress et donc cette béquille est apparue. Le plugin de mise en cache a été installé et configuré par des personnes connaissant déjà, et il est sorti immédiatement de la boîte. Ainsi, le problème de mise en cache a été résolu. Pourquoi ce plugin a été choisi, je ne sais pas avec certitude. Pour autant que je sache, c'est l'un des plugins les plus populaires de ce type pour WP.
Compte tenu des points de vue, ils ont agi quelque peu différemment. Il est clair que le mécanisme d'origine a dû être abandonné. Je ne voulais pas refuser de prendre en compte les opinions elles-mêmes: au moins un bloc montrant comme "les articles les plus populaires de la semaine" y était lié. Tous les plugins pour l'enregistrement des vues, même s'ils étaient «amis» avec le plugin de mise en cache, se sont avérés très voraces et, le plus souvent, ont implémenté le même mécanisme avec l'écriture et l'extraction de données de wp_postmeta. Pour un petit site, cela convient parfaitement. Pour un site avec des taux de fréquentation de pointe assez solides - plus: trop gourmand pour une si petite fonction. Ensuite, au fait, j'ai trouvé un hébergement payant et inutilisé pour les années à venir. Le plus simple et le moins cher. Les responsabilités de stockage, d'enregistrement et de retour des données sur les vues lui incombaient. Tout est asynchrone, c'est-à-dire même s'il tombe, le site principal continuera à afficher tranquillement des articles, des publicités et tout ce qu'il devrait afficher. Le stockage en ligne des données de visualisation a été attribué à Redis et le stockage à long terme à MySQL. Il tourne donc, il ne demande pas vraiment et mange 1 à 2% de la charge maximale autorisée sur cet hébergement.
Et donc, un temps assez long passe. Encore et toujours une vieille histoire. Un trafic assez puissant va sur le site et le site commence à chuter. Et encore une fois, je suis le seul spécialiste conditionnel éveillé dans la région. Bien sûr, je suis surpris de la répétition des événements. Ma première pensée est que quelqu'un a accidentellement désactivé la mise en cache. Mais non, dans le code source de la page du site que me donne le serveur tombant, je vois des signes d'un plugin de mise en cache qui fonctionne. Tout devrait bien se passer. Mais dans le panneau de contrôle du serveur, je vois qu'il n'y a plus de RAM, le nombre de requêtes de base de données est incroyable et tout est mauvais. Tout d'abord, j'ouvre la page avec la description du plugin, traverse rapidement ses yeux, ne trouve rien et quitte cette activité. L'étape suivante consiste à voir les statistiques. Je vois que le flux de trafic principal afflue sur le site à partir de Yandex.Zen. Et la demande qui mène l'utilisateur vers le site ressemble à ceci:
https://example.com ? utm_referrer = https:% 2F% 2Fzen.yandex.com
C'est-à-dire Yandex.Zen ajoute sa balise utm à l'adresse. Étant donné que le serveur est déjà complètement couché et ne me donne que 500, pour une raison quelconque, je ne peux pas vérifier clairement la théorie selon laquelle les pages avec une telle "pondération" ne sont pas mises en cache. Par conséquent, une autre «béquille» est née (elle a été remplacée par la suite): une redirection est ajoutée à .htaccess, qui convertit la demande avec les balises utm en une demande sans eux avant que WordPress et tous ses plugins puissants entrent en jeu. La machine redémarre et, le tour est joué, tout fonctionne: le site se charge rapidement, le serveur bruit tranquillement à basse vitesse. Comme rien ne s'est passé.
Ensuite, je me suis détendu et j'ai grimpé calmement en regardant les paramètres du plugin de mise en cache. Tout d'abord, la case à cocher «Ne pas mettre en cache les pages avec les paramètres GET», qui est là. Tout va bien, elle n'en vaut pas la peine. De plus, comme l'expérience l'a montré, le plugin gère la mise en cache des requêtes avec n'importe quel ensemble de paramètres arbitraires. S'il ne s'agit pas de balises utm (en fait, je n'ai redirigé que les demandes d'un certain type et je n'ai pas coupé toutes les balises utm).
Ici, j'ai soigneusement (en utilisant CTRL + F) regardé la page du plugin. Et j'ai trouvé dans la FAQ le glorieux paragraphe "Comment utiliser au mieux les outils de suivi utm_source dans Google Analytics avec ce plugin?". Il est clair que lors du premier examen superficiel, je l'ai ignoré en toute sécurité: il ne semble y avoir rien à voir avec le problème. En même temps, d'ailleurs, ce n'est pas très informatif et n'offre aucune solution spécifique.
La seule conclusion utile possible dans l'article: si vous avez un site WP avec le plugin WP Super Cache, alors vérifiez ce qu'il fait (ou pas), si vous soumettez une demande avec les paramètres «? Utm_referrer = https:% 2F% 2Fzen. yandex.com ", etc. Je ne suis pas sûr que lors de l'installation de ce plugin, tout le monde lit sa FAQ si attentivement. L'implémentation spécifique, apparemment, reste aux propriétaires du site: la dernière fois que j'ai regardé la mise à jour de ce plugin, je n'ai vu aucun changement concernant sa réaction étrange aux balises utm.
Mais l'histoire aurait été incomplète (et je ne l'aurais pas racontée) s'il n'y avait pas eu une autre confirmation de la loi de Murphy. Pendant que nous correspondions pacifiquement avec le propriétaire du site et regardions comment le site fonctionnait tranquillement pendant environ une heure ... le site est tombé. De façon inattendue et enfin. Il n'y a pas d'accès au panneau de contrôle du serveur, FTP, SSH et tout le reste ne fonctionne pas. Rien ne marche. Si avant cela ma pression n'a été que légèrement augmentée en résolvant le problème que J. Zen et le plugin de mise en cache ont provoqué (après tout, c'est un plaisir particulier de comprendre rapidement et de réparer quelque chose dans une dispute facile), alors une attaque de mini-panique entière m'est arrivée. Et seul le vague sentiment que quelques lignes dans .htaccess ne peuvent pas tout tuer une heure après avoir fait ces lignes n'a pas laissé le «mini» se transformer en quelque chose de plus complet. En général, après quelques minutes d'échange de messages surpris, nous sommes montés sur le compte personnel du fournisseur d'hébergement où réside le serveur. Et là, dans les tickets, nous avons trouvé un avertissement concernant "le travail technique de X à Y sur MSC". La chose la plus intéressante est qu'au bureau de poste, quelle que soit la façon dont nous avons cherché, nous n'avons trouvé aucun message de l'hébergeur à propos de ces travaux. Le billet avait au moins un jour. Avant cela, de tels messages étaient envoyés par la poste, et personne ne regarde généralement les tickets du service d'assistance (et du bureau d'accueil lui-même) généralement sans aucun besoin particulier. Par conséquent, ce qui s'est passé a été une grosse surprise. Après cela, nous avons grondé les yeux de l'hébergeur, ri, attendu que tout fonctionne et nous nous endormions.
Voici une histoire.