Dieser Artikel stammt vielmehr aus einer Reihe von "Hostess Notes". Nun, ein bisschen mehr über persönliche Erfahrungen und Aushöhlungen.
Wenn Sie sich mit WordPress-Sites befassen müssen, auf denen das WP Super Cache-Caching-Plugin installiert ist, kann der Artikel für Sie hilfreich sein. Ansonsten ist dies nur eine kurze Geschichte.
Kurz gesagt, der Anfang der Geschichte lautet: Es gab eine Website. Thematische Nachrichten und Informationen. Erstellt von einem unbekannten Assistenten auf CMS WordPress. Und genau so, wie es in diesem Moment von seinem Besitzer erlaubt wurde. Im Laufe der Zeit gewann die Website an Popularität, die Anzahl der Besucher wuchs. Die Seite selbst "verdient" auf Werbung. Das heißt, Je mehr Besucher, desto besser. Irgendwann, während der Spitzenlast, begann sich die Site zu drehen: Seiten wurden langsam geladen und so weiter. Aber bis sich der Schwanz pickte, bewegte sich natürlich niemand wirklich. Der Hahn erschien in dem Moment, als der Ort ein Ereignis abdecken sollte, das die Aufmerksamkeit der Öffentlichkeit auf sich zog. Besucher kamen herein, die Website ging unter und alle geschätzten Einnahmen schmolzen vor unseren Augen. Aufgrund der Umstände musste ich als Beatmungsbeutel fungieren. Ich habe damals
einen Artikel darüber geschrieben. Meine Entscheidung war gruselig (nicht wiederholen), aber das Hauptziel wurde erfüllt - Träume wurden gerettet. Meistens.
Natürlich war niemand daran interessiert, eine ähnliche Situation zu wiederholen, und arbeitete an der Website. Zunächst fanden sie die Gründe für den Ausfall und die hohe Auslastung des Servers heraus. Sie waren an der Tagesordnung: das Fehlen einer Caching-Site als solche und eines schlecht implementierten Mechanismus zum Aufzeichnen und Anzeigen der Anzahl der Artikelansichten. Letzterer selbst hat eine anständige Last erzeugt: Bei jeder Anforderung für die Artikelseite nahm er die Anzahl der Ansichten dieses Artikels aus der Datenbank, zeigte sie an, fügte eine hinzu und schrieb sie zurück in die Datenbank. Gleichzeitig wurde die Tabelle
wp_postmeta mit Metadaten zur Speicherung verwendet (wie es in WP zu heißen scheint). In dem die Masse völlig irrelevant für die Buchhaltung von Informationen gespeichert war und die sehr groß war.
Das Caching-Problem wurde einfach gelöst: In einer ruhigen Umgebung wurde das WP Super Cache-Plugin normal installiert. Was mir viele, wenn ich mich richtig erinnere, geraten haben, anstelle der unheimlichen Krücke, die ich in den Kommentaren zu meinem Artikel gebaut habe, zu tun. Ehrlich gesagt habe ich damals und heute schlecht im WordPress-Ökosystem navigiert und daher erschien diese Krücke. Das Caching-Plugin wurde von bereits bekannten Personen installiert und konfiguriert und war sofort einsatzbereit. Damit war das Caching-Problem gelöst. Warum dieses Plugin ausgewählt wurde, weiß ich nicht genau. Soweit ich weiß, ist dies eines der beliebtesten Plugins dieses Typs für WP.
Angesichts der Ansichten verhielten sie sich etwas anders. Es ist klar, dass der ursprüngliche Mechanismus aufgegeben werden musste. Ich wollte mich nicht weigern, die Ansichten selbst zu berücksichtigen: Zumindest ein Block, der wie "die beliebtesten Artikel der Woche" zeigt, war damit verbunden. Alle Plugins zum Aufzeichnen von Ansichten, auch wenn sie mit dem Caching-Plugin "befreundet" waren, erwiesen sich als sehr unersättlich und implementierten meistens denselben Mechanismus beim Schreiben und Extrahieren von Daten aus wp_postmeta. Für einen kleinen Standort ist dies durchaus geeignet. Für einen Standort mit relativ soliden Spitzenbesuchsquoten - nicht mehr: zu gefräßig für eine so kleine Funktion. Dann tauchte ich übrigens jahrelang für bezahltes und unbenutztes Hosting auf. Am einfachsten und billigsten. Die Verantwortung für das Speichern, Aufzeichnen und Zurückgeben von Daten über Ansichten lag bei ihm. Alles ist asynchron, d.h. Selbst wenn es herunterfällt, werden auf der Hauptseite weiterhin leise Artikel, Anzeigen und alles angezeigt, was angezeigt werden soll. Die Online-Speicherung der Anzeigedaten wurde Redis und die Langzeitspeicherung MySQL zugewiesen. Es dreht sich also, es fragt nicht wirklich und verschlingt 1-2% der maximal zulässigen Last auf diesem Hosting.
Und so vergeht eine ziemlich lange Zeit. Wieder Nacht und wieder eine alte Geschichte. Ziemlich starker Verkehr geht auf die Site und die Site beginnt zu fallen. Und wieder bin ich der einzige Spezialist für wache Bedingungen in der Region. Natürlich bin ich überrascht über die Wiederholung von Ereignissen. Mein erster Gedanke ist, dass jemand versehentlich das Caching deaktiviert hat. Aber nein, im Quellcode der Site-Seite, die mir der fallende Server gibt, sehe ich Anzeichen dafür, dass ein Caching-Plugin funktioniert. Alles sollte in Ordnung sein. Aber in der Server-Systemsteuerung sehe ich, dass kein RAM mehr vorhanden ist, die Anzahl der Datenbankabfragen unglaublich ist und alles schlecht ist. Zuerst öffne ich die Seite mit der Beschreibung des Plugins, laufe schnell durch ihre Augen, finde nichts und verlasse diese Aktivität. Der nächste Schritt ist das Anzeigen der Statistiken. Ich sehe, dass der Hauptverkehrsfluss von Yandex.Zen in die Site fließt. Und die Anfrage, die den Benutzer zur Site führt, sieht folgendermaßen aus:
https://example.com ? utm_referrer = https:% 2F% 2Fzen.yandex.com
Das heißt, Yandex.Zen fügt der Adresse sein utm-Tag hinzu. Da der Server bereits vollständig im Liegen liegt und mir nur 500 gibt, kann ich aus irgendeinem Grund die Theorie, dass Seiten mit einer solchen "Gewichtung" nicht zwischengespeichert werden, nicht eindeutig überprüfen. Daher wird eine weitere „Krücke“ geboren (sie wurde später ersetzt): Zu .htaccess wird eine Umleitung hinzugefügt, die die Anfrage mit utm-Tags in eine Anfrage ohne diese umwandelt, bevor WordPress und alle seine leistungsstarken Plugins ins Spiel kommen. Die Maschine startet neu und voila, alles funktioniert: Die Site wird schnell geladen, der Server raschelt leise bei niedrigen Geschwindigkeiten. Da ist nichts passiert.
Dann entspannte ich mich und kletterte ruhig und beobachtete die Einstellungen des Caching-Plugins. Zunächst das Kontrollkästchen "Seiten nicht mit GET-Parametern zwischenspeichern". Alles ist gut, sie ist es nicht wert. Wie das Experiment gezeigt hat, bewältigt das Plugin das Abfrage-Caching mit einem beliebigen Satz beliebiger Parameter. Wenn dies keine utm-Tags sind (tatsächlich habe ich nur Anforderungen eines bestimmten Typs umgeleitet und nicht alle utm-Tags abgeschnitten).
Hier habe ich mir (mit STRG + F) die Plugin-Seite genau angesehen. Und ich fand dort in den FAQ den herrlichen Absatz "Wie sollte ich die Tracking-Tools utm_source in Google Analytics mit diesem Plugin am besten verwenden?". Es ist klar, dass ich ihn bei der ersten flüchtigen Prüfung ignoriert habe: Es scheint nichts mit dem Problem zu tun zu haben. Gleichzeitig ist es übrigens nicht sehr informativ und bietet keine spezifische Lösung.
Die einzig mögliche nützliche Schlussfolgerung im Artikel: Wenn Sie eine WP-Site mit dem WP Super Cache-Plugin haben, überprüfen Sie, was sie tut (oder nicht), wenn Sie eine Anfrage mit den Parametern „? Utm_referrer = https:% 2F% 2Fzen. yandex.com "usw. Ich bin mir nicht sicher, ob bei der Installation dieses Plugins jeder seine FAQ so sorgfältig liest. Die spezifische Implementierung bleibt anscheinend bei den Site-Eigentümern: Als ich mir das Update dieses Plugins das letzte Mal angesehen habe, habe ich keine Änderungen bezüglich seiner seltsamen Reaktion auf utm-Tags gesehen.
Aber die Geschichte wäre unvollständig gewesen (und ich hätte es nicht erzählt), wenn es keine weitere Bestätigung von Murphys Gesetz gegeben hätte. Während wir friedlich mit dem Eigentümer der Site korrespondierten und beobachteten, wie die Site ungefähr eine Stunde lang leise funktionierte ... fiel die Site. Unerwartet und endlich. Es gibt keinen Zugriff auf das Server Control Panel, FTP, SSH und alles andere funktioniert nicht. Nichts funktioniert. Wenn zuvor mein Druck durch die Lösung des Problems, das J. Zen und das Caching-Plugin ausgelöst haben, nur geringfügig erhöht wurde (schließlich ist es ein besonderes Vergnügen, schnell etwas zu verstehen und zu beheben), ist mir eine ganze Mini-Panikattacke passiert. Und nur das vage Gefühl, dass ein paar Zeilen in .htaccess eine Stunde nach dem Erstellen dieser Zeilen nicht alles töten können, ließ den „Mini“ nicht zu etwas Vollständigerem werden. Im Allgemeinen sind wir nach ein paar Minuten des Austauschs überraschter Nachrichten auf das persönliche Konto des Hosting-Anbieters gestiegen, auf dem sich der Server befindet. Und dort fanden wir in Tickets eine Warnung über "technische Arbeit von X nach Y auf MSC". Das Interessanteste ist, dass wir bei der Post, egal wie wir gesucht haben, keine Nachrichten vom Hoster über diese Werke gefunden haben. Das Ticket war mindestens einen Tag alt. Zuvor gingen solche Nachrichten per Post ein, und normalerweise sieht sich niemand Tickets des Support-Service (und des Büros des Hosters selbst) an, normalerweise ohne besonderen Bedarf. Daher war das, was passiert ist, eine große Überraschung. Danach schimpften wir mit den Augen des Gastgebers, lachten, warteten, bis alles funktionierte und gingen schlafen.
Hier ist eine Geschichte.