Warum werden Transienten vorzeitig gelöscht?


7

Sie würden denken, dass ein vorübergehender Satz, der zu einem bestimmten Zeitpunkt abläuft, bis zu diesem Zeitpunkt existieren würde. Leider scheinen sie früher aus der Datenbank zu verschwinden, sowohl beim Test als auch bei der Produktion. Versuchen Sie als einfaches Beispiel, um dieses Verhalten zu sehen:

<?php
/*
Plugin Name: Test transient
Description: Show transients bug
Version: 0.1
*/

add_action( 'wp_head', 'doAnAlert' );

function doAnAlert()
{
    if( !get_transient( 'my_messageDismiss' ) )
    {
        //Transient nonexistent or expired
        ?><script> alert("This alert should also show again in 24hr"); </script>
        <?php

        set_transient( 'my_messageDismiss', 'dismissed', 86400); //Set for a day
    }

}

Was fehlt mir an der Transients-API? Die Warnung wird Stunden später und nicht einen Tag später angezeigt.


Jeder noch so unwichtige Treffer auf Ihrer Website löst diese Warnung aus und regeneriert den Übergang. Möglicherweise möchten Sie einen besseren Test verwenden, z. B. eine Überprüfung, um is_adminsicherzustellen, dass Sie die einzige Person sind, die ihn überprüft, und keine anderen Anrufe oder Überprüfungen von Ihr Browser löst es unbeabsichtigt aus. Stärkere Testkontrollen!
Tom J Nowell

@ TomJNowell mache ich, und dies ist nur zum Zweck eines minimalen Tests, und laut Dokumentation gibt es false zurück, wenn der Transient nicht existiert : codex.wordpress.org/Function_Reference/get_transient
NoBugs

wahr, es gibt falsch zurück, ich bezog mich mehr darauf, wenn Ihr Test ausgeführt wird, false ===wäre auch besser
Tom J Nowell

Antworten:


10

TL; DR

  • Der WordPress-Teil der vorübergehenden Verarbeitung ist solide, alles ist ziemlich präzise
  • Transienten verwenden den Objektcache anstelle des Datenspeichers für nicht standardmäßige Implementierungen
  • Dies bedeutet, dass einige Back-End-Cache-Systeme den Cache entfernen, auf den in letzter Zeit nicht zugegriffen wurde
  • Fazit: Es ist kein WordPress-Fehler, es hängt nur davon ab, wie Ihr Back-End-Cache eingerichtet ist

Sie könnten Transienten präziser machen, aber es erfordert eine Optimierung des Back-End-Cache, die ich nicht empfehle, wenn Sie nicht wissen, was Sie tun. Zu viel Cache könnte den gegenteiligen Effekt haben.

Aber nehmen Sie auch dann nicht an, dass es 100% genau ist.


Aus dem WordPress-Codex :

Jeder scheint falsch zu verstehen, wie ein vorübergehender Ablauf funktioniert. Das lange und kurze daran ist: Vorübergehende Ablaufzeiten sind eine maximale Zeit. Es gibt kein Mindestalter. Transienten verschwinden möglicherweise eine Sekunde nach dem Einstellen oder 24 Stunden, sind aber nach Ablauf der Gültigkeitsdauer nie mehr vorhanden.

Sie sollten immer eine Fallback-Methode haben.


Warum passiert es?!

WordPress macht Transienten nur ungültig, wenn versucht wird, sie zu lesen (was in der Vergangenheit zu Problemen bei der Speicherbereinigung geführt hat). Dies ist jedoch für andere Backends nicht garantiert.

Transienten verwenden den Objektcache für nicht standardmäßige Implementierungen. Der wirklich wichtige Teil, der hier zu beachten ist, ist, dass der Objektcache ein Cache und absolut kein Datenspeicher ist. Dies bedeutet, dass der Ablauf ein Höchstalter ist, kein Mindest- oder Sollwert.

Ein Ort, an dem dies leicht passieren kann, ist die Einstellung von Memcache im LRU-Modus (Least Recent Used). In diesem Modus verwirft Memcache automatisch Einträge, auf die in letzter Zeit nicht zugegriffen wurde, wenn Platz für neue Einträge benötigt wird. Dies bedeutet, dass Daten, auf die weniger häufig zugegriffen wird (wie sie von Cron-Daten verwendet werden), verworfen werden können, bevor sie ablaufen.

Lesen Sie mehr aus diesem Artikel , es ist sehr gut erklärt.


Caching?

Es gibt viele verschiedene Systeme, aber hier ist ein Beispiel dafür, wie das Zwischenspeichern von MySQL-Datenbanken im Allgemeinen funktioniert. Ich bin mir nicht sicher, wie hilfreich es ist, das Zwischenspeichern von Transienten zu verstehen, aber ich denke, es könnte nicht schaden.

  • Daten aus jeder unterschiedlichen Abfrage werden zwischengespeichert
  • Jede zwischengespeicherte Daten erhält einen Wert (kompliziertere Abfrage ==höherer Wert)
  • Diese Werte werden dekrementiert (wie ein Countdown-Timer, wenn Sie so wollen)
  • Das Caching-System überprüft diese Werte in Intervallen
  • Wenn einer dieser Werte Null erreicht, wird dieser Cache zerstört
  • Wenn dieselbe Abfrage erneut ausgeführt wird, wird der Wert auf den Anfangswert zurückgesetzt

Also ... Was können Sie daraus schließen? Es macht keinen Sinn, Transienten einzustellen, die:

  • Zu einfach
  • Nicht häufig verwendet

Weil diese in den meisten Fällen sehr schnell zerstört werden. Ich hoffe, dies gibt Ihnen ein klareres Bild davon, wie das Caching im Allgemeinen funktioniert. Es priorisiert häufige und komplizierte Daten gegenüber einfachen und selten verwendeten Daten.

Hinweis: Die Cache-Erklärung enthält viele Verallgemeinerungen, die das Verfolgen und Verstehen erleichtern.


Gute Antwort, aber dies ist etwas unvollständig - wenn transient eine Anfrage an einen Server zwischenspeichert, die lange dauern kann, und im Idealfall die gesamten X Minuten lang aufbewahrt wird, bevor diese lange Anfrage gestellt und die Daten erneut heruntergeladen werden müssen Wie können wir den Cache so einstellen, dass er Transienten ignoriert, die näher an X Minuten liegen, anstatt zu sagen, dass er jede Minute gelöscht wird und mehr lange Seiten geladen werden?
NoBugs

Nein, es ist nicht unvollständig, dies ist ein völlig anderes Thema (sogar Technologie) und außerhalb des Bereichs für diese Site. Wenn Sie mehr darüber erfahren möchten, würde ich empfehlen, andere (Datenbank-, Caching-bezogene) Stack Exchange-Sites auszuprobieren. Datenbank und Caching sind so fragil und situativ, dass Sie normalerweise einen gut ausgebildeten Ingenieur einstellen müssen, um es richtig zu machen (es sei denn, Sie haben eine kleine Liga-Site). Sie werden niemals eine vollständige und (für Ihre Situation) richtige Antwort von der Online-Q & A-Site erhalten. Es gibt so viele Variablen, Datenbank-, Software- und Hardwarespezifikationen, Datenverkehr usw., die Sie berücksichtigen müssen.
N00b
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.