Diskussion: Wie implementieren? about cache_warmup HOT 22 CLOSED

Wenn man das frontend crawled hat es den vorteil dass alle caches generiert werden (nicht nur media manager) und zugleich dass nur die generiert werden welche auch verwendet sind.

Man müsste sicherstellen dass der crawler alle rechte hat und auch seiten hinter einem login besucht etc

from cache_warmup.

Man könnte es auch so machen, dass man optional pro MP-Kategorie manche Typen ausschließen kann, oder auf manche Typen beschränken. Oder irgendwas in der Richtung.

from cache_warmup.

Ich habe zwar keine andere Idee, aber Variante 3 finde ich nicht wirklich gut.
Stell dir vor, du hast einen Fullscreenslider der nur für bestimmte Bilder gedacht ist, die entsprechend groß (3 MB) hochgeladen wurden. Alle kleineren Inhaltsbilder, die ebenfalls aber kleiner hochgeladen wurden (300kb), werden jetzt für diesen Typ angelegt. Das könnte heißen das die kleineren Bilder hochskaliert werden um dem Typen zu entsprechen. Da hast die Platte ziemlich schnell voll.

from cache_warmup.

Eine Generierung der Inhalte (structure) vorab ist eigentlich unnötig, weil dies nur sehr wenig Zeit benötigt, oder?

Ich hätte jetzt gesagt: Wenn schon, denn schon.
Wobei man auch ruhig mit dem MediaManager beginnen kann, und das dann noch später einbauen könnte.

Wie man aber nun am besten vorgeht beim MM, da bin ich mir unsicher. Ich fände es nicht so schön, wenn einfach für alle Typen die Bilder generiert werden würden, obwohl vielleicht ein Typ eigentlich nur für ganz bestimmte Bilder vorgesehen ist.

Auch zu berücksichtigen ist übrigens, dass der MM nicht mehr auf Bilder beschränkt ist, sondern für jegliche Medien gedacht ist. Auch wenn es bisher hauptsächlich Effekte für Bilder gibt.

from cache_warmup.

media1-10 und medialist1-10 praktisch wäre, wenn man diesen bereits den Mediatyp übergeben könnte. Dann kann das Anlegen der Caches für die ausgewählten Medien bereits direkt erfolgen.
REX_MEDIA[id=1 widget=1 preview=1 mediatypes=XYZ,ZXY]

from cache_warmup.

Variante 1 ist aus meiner Sicht die beste. Man braucht dafür keine EPs oder Hacks oder sowas und hat zusätzlich nur die Bilder generiert, die auf der Webseite wirklich benötigt wurden. Das Thema hatten wir ja schon mal und ein Crawler, der alle Unterseiten aufruft, habe ich bereits (für mein Sphider-Addon). Nachteil (aktuell noch), dass Seiten die offline oder geschützt sind (Stichwort Userbereich) würden hier nicht berücksichtigt werden.

from cache_warmup.

Ich fände es nicht so schön, wenn einfach für alle Typen die Bilder generiert werden würden, obwohl vielleicht ein Typ eigentlich nur für ganz bestimmte Bilder vorgesehen ist.

Kommt sowas wirklich vor? Ich kenne es nur so, dass Mediatypen passend zum Layout eingesetzt werden, damit Bilder gut in Spalten oder Grids oder Lightboxen oder was auch immer passen. Heutzutage benötigt man ja auch gar nicht mehr allzu viele davon, weil man Bilder aus verschiedenen Gründen (etwa Responsive, HiDPI) nicht mehr pixelgenau ausgibt, sondern per CSS skaliert. Normalerweise sollte eine typische Website heute mit 2-3 Mediatypen auskommen, während früher je nach Komplexität für diverse Spaltensätze Bilder generiert werden mussten.

Aus meiner Sicht wäre es kein Problem, Bilder in allen vorhandenen — inklusive der redaxo-internen — Mediatypen zu generieren, selbst wenn am Ende nicht alle benötigt werden.

WordPress übrigens generiert alle definierten Thumbnails direkt nach Upload, unabhängig davon, ob sie verwendet werden.

from cache_warmup.

Das Thema hatten wir ja schon mal und ein Crawler, der alle Unterseiten aufruft, habe ich bereits (für mein Sphider-Addon).

Den Crawler hatten wir im Zusammenhang mit der Suche. Dort ist er sehr sinnvoll. In Fall des Cache-Generierens allerdings halte ich den Zugriff »von außen« als nicht sonderlich sinnvoll, weil der Zugriff von innen ja bereits vollständig zur Verfügung steht und viel einfacher und performanter ist.
Oder?

from cache_warmup.

Kommt sowas wirklich vor?

Ich muss gestehen, dass ich es nicht einschätzen kann, da ich mit dem Thema wenig zu tun habe.

Man könnte auch erstmal den Weg gehen, und schauen, wie er sich in der Praxis macht.

from cache_warmup.

Ich baue aktuell einen neue Webpräsenz für einen Fotografen. Wenn hier alle Bilder in allen möglichen Medientypen vorgeneriert werden bekomme ich sicher ein Platzproblem. Es gibt Medientypen für Slides, Parallax, Tumbs, 2x 3x 4x Retina, verschiedne Crops etc. ... da sammelt sich was. Aktuell hat er ca. 1000 Fotos auf der Seite. Die Ausgangsbilder sind auch nicht gerade klein.

from cache_warmup.

@skerbis, okay, damit hast du gerade den Worst Case definiert. Jetzt müssen wir irgendwie aus der Nummer rauskommen ;)

from cache_warmup.

Wenn man das frontend crawled hat es den vorteil dass alle caches generiert werden (nicht nur media manager) und zugleich dass nur die generiert werden welche auch verwendet sind.

@staabm, aber wird das nicht kompliziert im Hinblick auf yforms/community? Ich fände es schade, wenn man die auslassen oder nur halbherzig beachten würde, denn auf manchen Websites bilden sie u. U. den Großteil des Datenbestands ab.

from cache_warmup.

Gibt es einen Funktionsaufruf der es ermöglicht in einem Slice die URL für den Medientyp zu generieren und so evtl. dann den Cache auch gleich mit zu erzeugen? Sowas wie mediamanagerurl(''bildxy.jpg, "thumb"); - Das könnte doch bei den Blöcken evtl. hilfreich sein. (Denn oft befinden sich diese nicht in eine A-Tag)

from cache_warmup.

aber wird das nicht kompliziert im Hinblick auf yforms/community? Ich fände es schade, wenn man die auslassen oder nur halbherzig beachten würde, denn auf manchen Websites bilden sie u. U. den Großteil des Datenbestands ab.

welches Problem siehst du konkret?

from cache_warmup.

welches Problem siehst du konkret?

Der Crawler würde nur Links folgen. Sollten Inhalte nicht verlinkt sein oder auf wundersamen proprietären Wegen geschützt sein — REDAXO ist bekanntlich ein großes Feld für Bastler ;) —, so dass der Crawler nicht rankommt, würde hier der Cache nicht generiert.

Mir scheint, der Weg von innen wäre deutlich robuster.

from cache_warmup.

hmm die Rechte geschichte könnte durchaus knifflig werden.

würdest du also eher ein weg gehen wie es das cron addon tut.. eine api definieren wie andere addons sich in den mechanismus einklinken können und dann deren adapter mitbenutzen.

from cache_warmup.

@staabm Das kann ich nicht beurteilen. Aber ich würde es gerne schlicht und robust machen. Aktuell scheint mir am sinnvollsten zu sein, die Datenbank auf Vorkommen von Medien in allen Bereichen zu filtern und diese in allen Varianten zu generieren — sofern es keine sinnvolle Möglichkeit gibt, herauszufinden, welche Mediatypes pro Medium verwendet werden.

Aber ich denke, das könnt ihr Core-Devs — und die anderen PHP-Devs, ich bin ja nichtmal einer — besser beurteilen.

from cache_warmup.

Hey,
ich habe gestern nochmal überlegt und bin der Meinung, dass wir Variante 3 umsetzen sollten: Alle Bilder erfassen und in allen Mediatypes generieren. Das ist die einfachste und sicherste Lösung, denn damit werden alle verwendeten Bilder — und nur die — erfasst.

Die anderen Varianten erfordern ein Crawlen und/oder Parsen der Inhalte, und ich denke, damit wird man nie zuverlässig alle verwendeten Bilder erfassen können. Ganz einfach deshalb, weil a) der Crawler nur das sieht, was public und untereinander verlinkt ist, und weil b) ein Parsen aller Inhalte nicht sinnvoll erfassen kann, was über Parameter, URLs oder sonstige Trigger ausgeliefert wird. Stellt euch eine Bildergalerie vor, die Inhalte anhand von URL-Parametern ausliefert: Sowas werden wir nicht automatisch parsen können.

Variante 3 wird das alles auffangen, und sie lässt sich für mein Empfinden sehr einfach implementieren. Sie wird zuverlässiger, schneller und robuster sein als die anderen Varianten. Sie hat lediglich den Nachteil, mehr Speicherplatz zu benötigen. Das mag in wenigen Fällen ein Problem sein, aber ich vermute und hoffe, ein Großteil der Websites würde mit der Variante prima auskommen.

Alternativ — falls ihr andere Meinungen dazu habt — könnten wir auch zwei Varianten bauen. Die zweite Variante würde crawlen und parsen.
— Ich möchte gerne mit der ersten Variante loslegen :)

from cache_warmup.

Als ich Thomas’ Kommentar bemerkt habe, hatte ich bereits tief im Code gewühlt und irgendwie Lust, das alles noch weiter zu testen. Herausgekommen ist dabei das hier: #4 (comment)

Thomas, ich finde dein Argument sehr schlüssig, dass man nicht alle Bilder als Fullscreenslider-Variante generieren möchte. Andererseits habe ich — speziell nach der bisherigen Arbeit am Addon — keine Idee, wie man es sinnvoll anders machen könnte. Ich denke nicht, dass wir sinnvoll und sauber herausfinden können, welche Bilder mit welchen Mediatypes verwendet werden. Und als Fallback bleibt dann nur, schlicht alle Mediatypes zu verwenden.
— Aber falls es solche Möglichkeiten gibt: Lasst es uns gerne probieren!

Als Gegenargumente würde ich noch anbringen:

1. Speicherplatz gibt es inzwischen reichlich. Wenn wir mit dem Cache Warmup unnötiges Bildmaterial generieren ist das sehr schade, aber es stört hoffentlich in den meisten Fällen nur sehr bedingt.
2. Man sollte keine so großen Bilder über den Media Manager generieren lassen, die für einen Fullscreenslider verwendet werden. Das benötigt zum einen sehr viel RAM — ich wette ein Nogger Choc, dass sie einem beim 1&1 Shared Hosting mit 32 MB RAM um die Ohren fliegen. Und selbst 64 MB wären in solchen Fällen arg knapp. —, und liefert zum anderen vielleicht nicht die Qualität, die man sich in einem prominenten Slider wünscht. Dort möchte man doch viel lieber hochwertiges Bildmaterial einbringen, das passend geschnitten, auf die richtige Größe skaliert und optimal komprimiert wurde.

from cache_warmup.

Ich habe das Addon nun finalisiert und eine erste Beta zum Testen erstellt: https://github.com/FriendsOfREDAXO/cache-warmup/releases/tag/1.0-beta1

from cache_warmup.

Update: Es gibt inzwischen einige weitere Releases unter https://github.com/FriendsOfREDAXO/cache_warmup/releases/

from cache_warmup.

Das Release für Version 1.0.0 liegt vor, deshalb würde ich die Diskussion hiermit vorerst beenden. Wenn ihr vorhabt, die Implementierung in eine andere Richtung zu bringen, macht gern ein neues Issue auf.

from cache_warmup.