cache_warmup
cache_warmup copied to clipboard
FriendsOfREDAXO
Größe der Chunks einstellbar machen / Repeater implementieren
Die Bilder und Seiten werden in "Chunks" eingeteilt: https://github.com/FriendsOfREDAXO/cache_warmup/blob/master/boot.php#L8-L11 Es wäre hilfreich, wenn man den "max" Wert (zumindest der Bilder) einstellen könnte. Ich habe schon mehrfach den Fall gehabt, dass ich den max Wert auf 30 oder 20 setzen musste, damit mir der Prozess nicht abschmiert. Das wäre über ein einfaches Select im Cache Warmup Reiter unter System machbar.
Oh, interessant zu hören. Wir hatten ja, als die Chunkgrößen implementiert wurden, versucht, ein gutes Mittelmaß zu finden. Die Werte werden abhängig von der maximalen Scriptlaufzeit des Servers gesetzt und liegen aktuell bei Scriptlaufzeit * 0.4, also 12 Bilder bei 30 Sekunden, 24 bei 60 Sek. und 36 bei 90 Sekunden. Das Limit liegt bei 50 Bildern.
Ich würde ganz gerne Benutzereinstellungen vermeiden, um das AddOn möglichst schlicht zu halten. Meinst du, wir könnten einfach die Werte etwas besser justieren? Vorschlag für Bilder:
Alt: 'min' => 10, 'max' => 50, 'ratio' => 0.4
Neu: 'min' => 10, 'max' => 40, 'ratio' => 0.3
Bei Skriptlaufzeiten von 30, 60, 90, 120, 180 würden somit 10, 18, 27, 36, 40 Bilder generiert.
@IngoWinter Würde das dein Problem wohl lösen? Könntest du deine aktuell betroffene Seite mal damit testen?
Die aktuell betroffene Seite hat eine Skriptlaufzeit von 120 Sekunden. Ich hatte die maximale Chunkgröße auf 20 gesetzt, und er ist mir trotzdem noch 3 oder 4 mal abgeschmiert. Ich vermute, dass das an der Größe der Originalbilder liegt. Wenn in einem Chunk ein paar mit 4000px Seitenlänge bei sind, dauerts wohl länger.
Wenn in einem Chunk ein paar mit 4000px Seitenlänge bei sind, dauerts wohl länger.
Denke ich auch und daher wird man m.E. auch kein geeignetes Mittelmaß finden können.
Okay, dann sollten wir statt Benutzereinstellungen, die man erklären müsste, und die die Bedienung des AddOns komplizierter machen, vielleicht lieber eine Art Repeater einbauen: Wenn bei der Bildgenerierung ein Timeout kommt, lassen wir den betroffenen Chunk noch X mal durchlaufen, bevor wir den Prozess abbrechen.
Wie wäre das?
Wie wäre das?
d.h. sobald der Repeater eingereift wird der chunk wiederholt, aber nur noch die teile des chunks neu berechnet die beim 1. rutsch nicht generiert werden konnten?
Der Repeater wiederholt nochmal alle Elemente des Chucks, jedoch laufen die bereits generierten Elemente schnell durch (dafür sorgt der Media Manager, nicht Cache-Warmup), so dass der Prozess genügend Zeit für die noch nicht generierten Elemente übrig hat.
Ich habe mit #81 sowieso ein paar Umbauten auf dem Tisch, dann würde ich den Repeater gleich mit implementieren.
Ich bitte darum, hier eine Optionsseite zu bieten.
In unserem Fall hat der Cache-Warmup bei 33 Seiten, die gleichzeitig generiert wurden, abgebrochen - nicht jedoch, wenn diese einzeln generiert wurden.
Der Repeater würde das Problem eigenständig lösen, so dass keine Chunk-Konfiguration notwendig wäre und dem AddOn nachwievor eine Config-Page erspart bliebe. Das fände ich persönlich sehr sinnvoll.
Die notwendigen Umbaumaßnahmen – nicht nur für den Repeater – sind allerdings sehr aufwendig, und dafür fehlt mir aktuell leider Zeit und Muße, deshalb hatte ich das Assignment des GitHub-Issues wieder aufgehoben.
Weil die JS-Umstellung etwas aufwendiger ist (aus Callback-Hölle müssen Generators/Promises oder sogar async/await werden), könnt ihr solange den Cache-Warmup etwas ausbremsen, falls er euch um die Ohren fliegt. In der boot.php des project-AddOns folgendes anbringen, wobei ihr den Wert von $throttle auf einen beliebigen Prozentwert (100 entspricht volle Geschwindigkeit) verändern könnt:
// decelerate Cache Warmup addOn
rex_extension::register('PACKAGES_INCLUDED', function () {
$addon = rex_addon::get('cache_warmup');
$throttle = 50; // percent %
$addon->setConfig('chunkSizeImages', floor($addon->getConfig('chunkSizeImages') * $throttle / 100));
$addon->setConfig('chunkSizePages', floor($addon->getConfig('chunkSizePages') * $throttle / 100));
});
Wieso so kompliziert? wenn ich zum Beispiel wissen möchte, welches Bild oder welcher Artikel ein Problem macht, dann möchte ich genau ein Medium oder einen Artikel einzeln generiert sehen.
Alex, dann schreibst du als Value einfach eine 1 hin. Nur wird der Warmup dann sehr lange benötigen, weil pro Request nur ein Cachefile generiert wird.
#99 ist mein Vorschlag dazu, das über die GUI zu machen und damit den "Link zur Fehlerseite" wieder einen sinnvollen Nutzen zu geben.
Alex, dann schreibst du als Value einfach eine 1 hin. Nur wird der Warmup dann sehr lange benötigen, weil pro Request nur ein Cachefile generiert wird.
Fürs Protokoll, in https://github.com/alexplusde/media_manager_responsive/ nutze ich das und gehe mit dem Warm-Up konzeptionell anders an das Thema ran.
- Es wird nur ein Artikel pro Request generiert
- Bilder-Warmup vom Cache-Warmup wird komplett deaktiviert, weil
- Beim Einsatz von media_manager_responsive die Cache-Files im Aufruf des Artikels erstellt werden.
Cache-Warmup hat von Haus aus folgende Nachteile:
- Es ist intransparent, in welchem Artikel ein Fehler auftritt, wenn in einem Request mehrere Artikel gecached werden. Um es zu debuggen, muss man Code ändern, was man auf Live-Seiten nicht will.
- Cache-Warmup erstellt zu viele Media Manager-Cache-Daten auf Vorrat. Das wurde zwar versucht via EP zu lösen, ist aber kein Nobrainer, denn man muss vorher wissen oder sammeln, welche Medien überhaupt, und wenn ja, in welcher Kombination verwendet werden.
Meine Vorgehensweise hat folgende Vorteile
- Beim Durchlauf erkenne ich, in welchem Artikel (bzw. Aritkel-ID/Clang-ID) es einen Fehler gibt.
- Es werden nur tatsächlich benötigte/verwendete ManagerProfil-Bild-Kombinationen erstellt und nicht "auf Vorrat", wodurch Cache Warmup insg. schneller durchläuft und Cachefiles weniger Speicherplatz fressen.
- In einem Request werden dennoch mehrere Schritte auf einmal erledigt.
Ja, meine Lösung funktioniert nur dann, wenn Bilder mit Media-Manager-Profilen grundsätzlich via PHP verarbeitet werden (dort das Cachefile aufgerufen wird) und nicht einfach nur /media/profil/<?= $mediafile ?> in den Modul- oder Template-Code geschrieben wird. Auf diesen Zug müsste man aufspringen, um Cache-Warmup dafür sinnvoll nutzen zu können. Das ist aber aus PageSpeed-Sicht sowieso notwendig und sinnvoll, denn ich brauche immer zur Laufzeit die Breiten- und Höheninformationen des Cachefiles.
Ja, natürlich passiert es, dass dann manchmal Memory- oder Skriptlaufzeiten erreicht werden, aber dieses Problem gibt es ja unabhängig davon hier in #85 zu lösen - ein Repeater, der 2-3 Anläufe vor Abbruch unternimmt wäre dann in der Tat sinnvoll.
Ich schließe hier, weil aus diesem Issue keine Aktion entstehen wird. Die aktuelle Codebasis sollte besser nicht um weitere Funktionalität erweitert werden, sondern es sollten zuvor konzeptionell ein paar Dinge geändert werden, u. a.
- Filenames statt IDs nutzen, damit z. B. Informationen über responsive Bilder verarbeitet werden können
- POST- statt GET-Requests verwenden
- Chunks nicht mehr serverseitig aufteilen, sondern zusammen mit dem besagten Repeater im Frontend behandeln
- Reports und Fehler mittels API ins Backend übergeben
Das Konzept des AddOns möchte ich gerne beibehalten. Andere Konzepte können gerne in separaten AddOns umgesetzt werden.
Die aktuelle Codebasis sollte besser nicht um weitere Funktionalität erweitert werden, sondern es sollten zuvor konzeptionell ein paar Dinge geändert werden
Das Konzept des AddOns möchte ich gerne beibehalten.
Konzeptionelle Änderungen machen, aber das Konzept beibehalten. Da bin ich gespannt, wie das funktionieren soll.
Ich habe meine Konsequenzen daraus gezogen: https://github.com/alexplusde/cache_warm_up
Funktioniert bestens! Vielleicht eine Alternative für @IngoWinter - deine Anregungen sind bei mir willkommen.