Ich hatte die Idee für ’nen Grav Workaround, um den Speicher zu drücken. Es würde halt mind. 3-4 Tage dauern, bis ich mit Hugo auf dem jetzigen Stand wäre – bei fast gleichem Resultat am Ende. Ich schloss eine Directory mit tausenden Seiten aus und siehe da – die RAM Nutzung ging nach unten.
Die Seiten wurden nicht gescannt, zur Runtime eben aus Markdown + Twig zusammengebaut – dachte ich, denn alles funktionierte. Da schlug wohl noch der Browser oder PHP-Cache zu – Ernüchterung. Die Geschwindigkeit war um Welten besser – unter 100ms statt mehrerer Sekunden pro Seitenaufbau. Das Problem war außerdem, dass TNTSearch eben nur die erkannten Seiten indiziert. Die ganze Sache irgendwie hinzuhacken, für TNTSearch einen Index außerhalb zu bauen gab ich dann nach ein paar Stunden auf. Einfach mal die Config Variablen umzuschreiben brachte erwartungsgemäß nichts.
Na gut, verlorene Zeit – am Grav Template bauen und dem Suchen nach einem Workaround für den Speicherhunger. Am besten wäre eben ein cleverer Router, der nach dem RAM in der Directory nachschaut, die Sachen on-the-fly umkonvertiert. Am Ende ist das Grav CMS halt das falsche System für einen Wikivoyage Abklatsch. Ich werde das System aber mal für eigene kleinere Sachen nutzen. So löschte ich meinen gestrigen Kommentar zur Einbindung von SQLite Lookups und schaute wieder in die Hugo Docs. Die Seiten werden da sicherlich gut gebaut, nur fehlt mir dann die extrem wichtige Suchfunktion. Algolia kostet Geld.
Ab Mitternacht nahm ich Hugo unter die Lupe. Die Origanisation der Templates ist anders und komplizierter. Alles ist mit den vielen Directories fummeliger, bei den Post Sections scheinbar einfacher. Das kube-Theme steigt bei fehlendem bref aus. Ansonsten ist das alles schon brauchbar. Nur muss ich mich jetzt mit Go Templates beschäftigen, die eben ungewohnt komisch aussehen.
0 Responses to “Grav Workaround – doch nicht”