Kategorien
Edge Side Includes – Nachteile
Vor kurzem hatte ich eine „neue“ Technologie vorgestellt – Edge Side Includes genannt. Habe auch erklärt warum sie total toll ist und so weiter. Im letzten Satz kam dann das ABER, vielleicht ist ja doch nicht alles Gold was glänzt. Dieser Artikel soll ein paar Nachtteile aufdenken, die meiner Meinung nach existieren.
- Fehlende Framework-Unterstützung: ESI klingt zwar einfach, aber wenn das Framework es nicht unterstützt, dann kann es haarig werden. Das System muss ja so gebaut sein, dass jeder Snippet der Seite unabhängig vom Rest gerendert werden kann. Soviel ich weiß, ist Symfony2 das erste und einzige Framework derzeit auf dem PHP-Markt das es unterstützt. Nachträglich sowas einzubauen halte ich für sehr komplex.
- Overhead: Das ist jetzt für jedes Projekt eine eigenen Rechenaufgabe. Nehmen wir an, wir nutzen ein relativ schwergewichtiges Framework, welches 100ms braucht um hochzufahren. Jetzt besteht unsere Seite im einfachsten Fall aus zwei Teilen. Da wir dank ESI beide getrennt haben, müssen wir jetzt zwei mal das Framework hochfahren. 200ms einfach im Framework verbraten ist halt schon mal ein doofer Startpunkt für eine Hochlastseite. Wir wollten ESI vor kurzem auch bei einer relativ bekannten Seite einführen und sind daran gescheitert, dass zwei Teile der Seite gar nicht cachebar waren und somit ESI keine Beschleunigung gebracht hätte.
- Parallelität: Wer gerade den Overhead-Punkt nicht einfach nur überflogen hat, der hat sich sicherlich die Frage gestellt, warum man die zwei ESI-Includes nicht einfach parallel abholt und somit immer nur das Maximum der beiden Requests zu buche schlägt. Tja, ESI kann das leider nur sequentiell. Wobei ich gerade nicht genau weiß, ob es eine ESI-Einschränkung oder ob die Varnisch-Implementierung das Problem ist. Wenn man es aber mal genau betrachtet, kann es schon ganz logisch sein. Was wäre, wenn ein Include Cookies setzt und das andere darauf zurückgreifen will? Wenn immer mal eins von beiden zuerst fertig ist, hat man kein konsistentes Verhalten und debugging wird die Hölle. Heisenbug lässt grüßen.
Das waren jetzt erstmal die von mir gesehenen drei Nachteile. Ihr werdet sicherlich auch noch einiges beitragen können.
Ach ja, heute geht meine Elternzeit zu Ende. Nach zwei Monaten zu hause wieder mal richtig arbeiten. Ich sag euch dann wie es war.
Was ich auch irgendwie doof finde: der Browser bekommt von den einzelnen Teilen einer Seite nichts mit.
Die Komponente mit der kleinsten Lebensdauer bestimmt ja die Lebensdauer der gesamten Seite. Wenn die nun rum ist, so muss der Browser die gesamte Seite „besorgen“ obwohl ein großer Teil der Seite wieder derselbe sein wird … die Bestandteile, die noch nicht expired sind.
@Ilja: Guter Punkt, vielleicht ist es ja Zeit ESI auch im Browser zu implementieren.
Es macht natuerlich null Sinn eine Seite in zwei nicht cachbare Teile zu konvertieren. Aber sobald man einen Teil auch nur 10sek. cachen kann ist bei einer hightraffic Seite schon viel zu gewinnen.
Ich will auch noch mal schauen ob wir in einem Projekt folgendes Konzept umsetzen koennen:
Alle User ohne Javascript bekommen eine unpersonalisierte Seite oder im bestenfall ein kleines iframe mit persoenlichen Daten. Saemtlicher individualisierter Content wird ueber einen einzigen ESI block ausgetauscht und per JS an den relevanten Stellen eingefuegt. Bei Bedarf wird Content auch im localstorage/websql/indexdb/cookie im Browser gecached.
@Lukas: Da hatten wir uns auch eine Lösung zu überlegt, die relativ convinient war. Wenn du damit beginnst, melde dich mal kurz mit eurem Git-Repository, vielleicht kann man sich da ergänzen.
als einen ersten schritt habe ich im LiipCacheControlBundle einen listener eingebaut mit dem man flash messages in ein cookie verschieben kann. aktuell gibt es aber keine plaene an dem obigen konzept zu arbeiten. denke davor werden wir uns an das LCI-like konzept, ueber das ich kuerzlich gebloggt habe, machen
Die meisten Frameworks bringen ja ihr eigenes Cacheing mit wie z. B. Yii
=> http://www.yiiframework.com/doc/guide/1.1/de/caching.overview
Esi im Browser macht keinen Sinn, denn man müsste ja jede Seite in Fragmente teilen, was aus einem Request u. U. Dutzende macht. Da dauern die Requests im Normalfall ja länger als wenn man das ganze Dokument neu lädt.