zu viele unbenötigte Cache-Bilder müllen den Webspace zu #86
Comments
|
Das Thema wurde ganz am Anfang schonmal besprochen: #1 Aus meiner Sicht ist ein Crawler kaum sinnvoll zu implementieren:
Der aktuelle Weg ist sicherlich einfacher und robuster, alle Medien mit allen Medientypes zu generieren. (Macht WordPress übrigens auch so.) Aber klar, wenn man viele Medientypes verwendet und den Medienpool voll mit Bildern hat, braucht es unter Umständen einigen Speicherplatz. Das sollte man beim Hosting bedenken. |
|
Robust ist für mich nicht, wenn der Webspace überläuft und die Seite nicht mehr erreichbar ist, weil man den Cache startet. Und dass Wordpress das genauso macht, ist nicht unbedingt ein Pro-Argument ;) |
|
Puh, okay. Und könnte eine Lösung des Problems für dich sein, ein angemessenes Hostingpaket zu verwenden? Bei 1&1 gibt es gerade robuste 100 GB Webspace für 99 Cent im ersten Jahr. Unlimited Webspace kostet leider schon knapp 7 EUR im Monat, im zweiten Jahr sogar 10 EUR, schade! Falls wir doch lieber den Crawler nochmal diskutieren wollen, gerne wieder öffnen. ¯\_(ツ)_/¯ |
Aus diesem Grund verwende ich den CacheWarmup auch nicht. Die jetzige Lösung ist die Einfachere aber nicht wirklich zufriedenstellend. |
|
was ist das problem an den vielen dateien? |
Aktuelles Szenario: Wir Hosten zahlreiche kleine Kundenwebsites in Paketen auf unserem Server. Diese zu migrieren auf verschiedene Server und den Speicherplatz zu erhöhen, damit Dateien generiert werden, die niemals abgerufen werden, ist verrückt. Ich schätze, ich werde einfach auf das Addon in Zukunft verzichten und ggf. eine Webspider-App anschmeißen, der einmal alle tatsächlich benötigten Ressourcen anschubst. |
|
D.h. Dein webspace ist winzig oder du hast wirklich 50gb bilder mit cache warmup erzeugt? |
|
hab's oben ergänzt. 20 GB sind jetzt nicht gerade winzig, dafür, dass tatsächlich nur 500-1000 MB benötigt würden. |
|
Nur, dass wir uns da nicht missverstehen: Sagen wir, ich habe 5 verschiedene Anwendungen, Bilder auszugeben: hero, thumbnail (gallery), thumbnail (category), fullscreen, project_detail. Alle 5 Bildtypen bringen 2-3 verschiedene Auflösungen mit, Retina und ohne, um das Picture-Element mit entsprechenden srcset-Bildern auszuliefern. Macht 5x3x2=30 Cache-Bilder pro Medium (+ Backend-Medienpool-Profile). Benötigt würden aber nur 4-6 pro Medium - vor allem von den wenigsten auch die größten Fullscreen- und Header-Bilder. Das Schlimme ist jedoch auch, dass der Redaxo-Entwickler auch gar nicht erkennen kann, dass es gleich ein Problem geben wird. |
|
Hmm vllt solltest du dann kein cache warmup benutzen. Das system wird dir anlegen was gebraucht wird und du musst dich nicht über 500-1000mb dateien „ärgern“. |
|
Wohl wahr |
Nochmal: Besagter Spider wird nicht ansatzweise zuverlässig deinen Cache vorbereiten können, denn dafür müsste er alle Seiten und Inhalte kennen, die von REDAXO generiert werden, müsste sie in allen Kontexten und Modi erfassen und auf sie zugreifen dürfen, und müsste dann alle darauf verwendeten Medien in allen Kontexten und Modi erfassen und auf sie zugreifen dürfen. Selbst wenn wir uns eine imaginäre Website ausdenken, die maximal einfach gestrickt ist, deren Ressourcen eindeutig erfassbar sind, und die alle Inhalte auf jeden Request hin vollständig und in immer gleicher Form ausgibt, dann müsste dein Spider diese Website mehrfach mit unterschiedlichsten Viewports (Größe und Pixeldichte) aufrufen, um alle von dir angebotenen Bildgrößen einmal zu requesten und REDAXO damit zu veranlassen, die Caches zu generieren. Und das ist der einfachste Fall. Komplexere Fälle kann ich hier gar nicht ansatzweise bildlich skizzieren: Seiten und Inhalte, die für den Spider gar nicht erst erfassbar sind, weil sie nicht verlinkt sind, Benutzerrechte erfordern, aus YForm oder eigenen AddOns kommen, dynamisch generiert werden, abhängig von UserAgents sind, von POST/GET-Values, von Tages- und Nachtzeiten, per Zufall generiert werden, und deren enthaltene Bilder mit Custom-URLs kommen, abhängig von Viewports und Browsern geladen werden, erst beim Scrollen der Seite oder beim Blättern eines Sliders lazy eingebunden oder sonstwie mittels JS modifiziert werden, bis sie erstmalig im Browser ankommen. Viel einfacher und robuster ist der Weg von innen. Nur ist es leider so, dass REDAXO nicht hinterlegt hat, welche Bilder mit welchen Mediatypes generiert werden müssen, sondern dass diese Informationen oftmals in Variablen in Templates und Modulen stecken, so dass die Inhalte erst mal von REDAXO generiert werden müssen, bevor sie geparst werden können. Zudem ist das Parsen nicht ganz trivial, wenn Custom-URLs ins Spiel kommen. Deshalb generiert Cache-Warmup alle Bilder mit allen Mediatypes und nimmt in Kauf, dass das unter Umständen merklichen Speicherplatz einnimmt. Und damit sind wir wieder am Anfang: Speicherplatz ist heutzutage günstig zu bekommen, deshalb kann man das Problem mit den vielen Cachefiles vernachlässigen, wenn man erstmal erkannt hat, welche anderen Probleme man am Hals hätte, wenn man Cache-Warmup zu einem Crawler umbauen wollte. |
|
Eventuell kann man Abhängigkeiten zu den Medienpoolkategorien herstellen. Außerdem wäre es gut, wenn man CacheWarmup eigene Pfade beibringen könnte. So sehen unsere Bildpfade wegen dem picture/source aktuell so aus bzw. als Rohurl |
wie hängt das mit dem urpsr. hier diskutierten problem zusammen? |
Das dadurch viel weniger Cachedateien generiert werden? |
mit den infos aus #86 (comment) ist das für mich nicht ersichtlich. ich verstehe nicht was du damit sagen willst. |
Das sind zwei Punkte
Der andere Punkt ist, dass man CacheWarmup auch gezielt eigene Urls beibringen müsste, so dass ggf obige Urls ebenfalls vom AddOn erfasst werden. |
|
@staabm bei dem zweiten Punkt von Thomas geht es um dieses Thema: redaxo/redaxo#1635 Wenn man Ansatz 1 oder 2 verwendet, kann man Cache-Warmup nicht mehr sinnvoll nutzen, da Cache-Warmup natürlich nichts von den virtuellen Typen/Dateinamen weiß. |
|
Zum eigentlichen Thema hier im Issue: Wenn unnötig 20 GB Bilder entstehen, würde mich das ehrlich gesagt auch stören. Kann gar nicht genau sagen, was mich dran stören würde, aber ich würde dann Cache-Warmup glaube ich auch nicht nutzen. An den Spider-Ansatz glaube ich allerdings auch nicht wirklich. Ich finde hingegen den Ansatz mit den Kategorien gar nicht so verkehrt (habe es hier auch schon mal vorgeschlagen). |
|
Der Kategorieansatz hat nur einen Schönheitsfehler - Redakteure :) |
|
Wobei Cache-Warmup ja nichts wirklich kritisches ist. Es wäre also aus meiner Sicht nicht schlimm, wenn manche Bilder dann nicht vor-erzeugt würdem, da sie in einer falschen Kategorie sind. Oder wenn es deswegen ein paar Bilder zu viel gäbe. |
|
Oder wir schaffen nur einen EP oder so, über den man die zu erzeugenden Bilder filtern kann. Dann kann sich jeder selbst eine Logik überlegen. |
|
das macht vllt sinn.. dass man einne EP auslöst pro bild was generiert würde und mann kann in der extension enscheiden ob das bild generiert werden soll, oder übersprungen. |
Ich finde beides sinnvoll. Ich denke kaum, dass man für jedes neue Projekt immer wieder eine separate Logik erstellt. Da wäre mit der Kategorieansatz schon lieber, da einfacher zu händeln. |
Den eigenen Ansatz legt man sich dann in sein Team-eigenes Standard-Addon, in unserem Fall yakme. |
|
Ich glaub auch ehrlichgesagt, dass im Großteil aller Projekte die bisherige Arbeitsweise des Addons nicht weiter stört. Die 20GB von Alex klingen schon nach einer recht bild- und effektreichen Website. |
|
Es gibt sogar schon einen EP zum Filtern: https://github.com/FriendsOfREDAXO/cache_warmup/blob/master/lib/selector.php#L138 Vielleicht reicht der mir sogar schon, muss ich ggf. mal testen. |
|
Ach nee, darüber lassen sich nur Bilder als ganzes ausschließen, wir möchten aber ja nur bestimmte Kombis aus MM-Typ und Bild ausschließen. Das ist damit nicht möglich. Wenn man es so macht, wie @staabm sagt, also ein EP-Aufruf pro zu erzeugendes Bild, dann müsste hier noch ein EP hin: https://github.com/FriendsOfREDAXO/cache_warmup/blob/master/lib/generator_images.php#L44 |
|
Siehe PR #90 |
In der Art und Weise, wie cache_warmup funktioniert, werden ja alle Medienprofile mit allen Bildern multipliziert. Das führt dazu, dass das ganze Cache-Verzeichnis vollgemüllt wird mit Bildkombinationen, die niemals benötigt werden. Im schlimmsten Fall - und das ist uns jetzt passiert - ist der Webspace voll und nichts geht mehr.
Das ist unbefriedigend. Stattdessen sollte es einen Modus geben, der nur das Frontend crawlt und die Bilder generiert, die auch tatsächlich benötigt werden. Oder einen Modus, der ausschließlich Artikel aufwärmt ohne Medien.
The text was updated successfully, but these errors were encountered: