Warum ist WebsiteBaker eigentlich so schnell?

[okapi]

Nein, das ist keine Scherzfrage. Ich bin immer wieder erstaunt, warum WB im Vergleich zu allen anderen opensource CMS, die ich kenne, so eine erstaunlich gute Performance hat, sowohl im Backend als auch im Frontend, obwohl WB ohne Cachesystem arbeitet.

Dafür gibt's sicher einer programm-technische Erklärung...?

Wie stark die Performance von WB von der Zahl der Seiten abhängig? Ich bin gerade mit einem sehr kleinen WB-Testprojekt beschäftigt. Daher würden mich Erfahrungen von Usern, die grössere Websites mit WB realisiert haben, sehr interessieren.

Gruß
Michael

[Waldschwein]

Hallo!

Nun, es ist wohl so schnell, weil es eben kein Caching verwendet wie so ziemlich jede andere Software. 

Nein, das war natürlich auch ein Scherz... Ich denke es liegt schlicht daran, dass eine "Standard"-WB-Installation sehr wenige Datenbankabfragen benötigt, ein sehr einfaches Templatesystem aufweist mit nur ganz, ganz wenigen Dateien und insgesamt frei nach dem Prinzip "Nicht mehr als nötig, so viel wie nötig" das gesamte WB aufgebaut ist. Viele andere Softwares eben haben sehr viel mehr (Core-)Dateien, sehr viel mehr Datenbankabfragen und Tabellen, wesentlich mehr von diesem und jenem. Probleme kann es natürlich bei sehr großen WB Installationen geben, aber ich denke, dass auch eine große WB-Installation mit >100 Seiten durchaus sehr performant ist - aber wie gesagt, alles hängt von Modulen, von Droplets ab... Wenn man jetzt eine WB Seite >500 Seiten hat, auf jeder 3 Droplets und dazu noch 10 Module, dann kann ein ungecachtes WB je nach Serverkonfiguration bestimmt "ein wenig" in die Knie gehen, aber ob das dann wirklich als langsam zu bezeichnen wäre muss man einfach sehen. Zumindest kann ein nachträglich "hinzugefügtes" Cachingsystem nicht so schwer sein, einige WB-Installationen gibt es mit Caching, aber wie das zu realisieren ist bin ich überfragt... Und ich denke, normalerweise für 98% der Installationen ist Caching auch deutlich langsamer als keines.

Gruß Michael

[WebBird]

Ich denke, das hängt damit zusammen, daß WB keinen großen Overhead hat. Der Core ist eigentlich recht klein und aufgeräumt, es gibt keine kostspieligen Automatismen wie Hooks (das Einhängen "von außen" in vorhandene Prozesse) oder Callbacks ('bevor Du dies tust, guck mal nach, ob Du noch was anderes tun mußt'). Das ist in mancherlei Hinsicht eine Einschränkung, hat aber, wie man sieht, auch große Vorteile.

Soweit ich gehört habe, hat die Anzahl der Seiten keinen großen Einfluß auf die Performance. Dazu gibt es hier im Forum einige ziemlich aktuelle Beiträge, z. B. den, wo WB innerhalb kürzester Zeit 600.000 Zugriffe verarbeitet hat. Such mal danach. (Ich bin grad zu faul )

Es gibt eigentlich nur eine Stelle, wo sich eine hohe Seitenzahl schmerzhaft bemerkbar macht, und das ist die Seitenübersicht im Backend. Das ist ein offenes ToDo, an dem nach meinem Wissen bereits geforscht wird.

[erpe0812]

Hallo

also AMASP hat > 500 Seiten und etliche Module.
Aber selbst im Backend ist ein vernünftiges Arbeiten kein Problem.

Woran es liegt, weiss ich nicht 
Aber das es so ist finde ich gut.

Gruss

erpe

[WebBird]

Wenn man jetzt eine WB Seite >500 Seiten hat, auf jeder 3 Droplets und dazu noch 10 Module, dann kann ein ungecachtes WB je nach Serverkonfiguration bestimmt "ein wenig" in die Knie gehen, aber ob das dann wirklich als langsam zu bezeichnen wäre muss man einfach sehen.

Was sicherlich auch noch ein Aspekt ist: Der wohl am meisten genutzte Seitentyp dürfte WYSIWYG sein, und da sind die Inhalte einfach so in der DB gespeichert, wie sie hinterher auch ausgeliefert werden. Wenn nichts mehr groß zu verarbeiten ist, spart das natürlich Zeit.

Das geht zu Lasten der Wiederverwendbarkei t von Inhalten (etwa, wenn ich einen Textblock an anderer Stelle nochmal als Zelle in einer Tabelle verwenden möchte), aber zu Gunsten der Geschwindigkeit.

Edit: Achja, und WB benutzt im Frondend keinen Template Parser. Das Template "zieht" sich vielmehr die Seiteninhalte und das Menü, indem man die entsprechenden Aufrufe dort unterbringt. Das ist allemal schneller, als Platzhalter zu suchen und zu ersetzen.

[WebBird]

Aber selbst im Backend ist ein vernünftiges Arbeiten kein Problem.

Die Seitenübersicht braucht schon ein bißchen länger, bis sie fertig geladen ist, aber mehr als 10  :-DSekunden (nach Gefühl) sind es trotzdem nicht.

[erpe0812]

Die Seitenübersicht braucht schon ein bißchen länger, bis sie fertig geladen ist, aber mehr als 10  :-DSekunden (nach Gefühl) sind es trotzdem nicht.

Da wären Andere aber froh, wenn es bei ihnen so schnell gehen würde...

[WebBird]

Ohhhhhhhh, jaaaaaaaa! Aber hallo!!! Ich bin ein sehr ungeduldiger Mensch und warte nicht gern, aber die 10 Sekunden tun mir auch nicht weh.

[okapi]

Was für ein Echo! Danke für die vielen interessanten Aspekte!
Ich denke, die genannten Details sind für jeden, der mit WB beginnt, hilfreich!

Interessant zu wissen, dass eine große Zahl von Seiten auf Frontendseite nicht so viel bremst, wie man vermuten könnte.

Meiner Erfahrung nach spielt ja der Umfang der Datenbankzugriffe vor allem bei shared hosting eine enorme Rolle für die Performance, merkbar an der Tageszeitabhängigke it: mal läuft's befriedigend, mal unzumutbar langsam. Und WB hat da im direkten Vergleich (gleicher Hoster, gleicher Webspace, gleicher Datenbankserver) immer die Nase vorn.

Gruß
Michael

[mr-fan]

hi,

hab eine seite mit ca. 100 seiten...viele module, einige droplets....keine probleme

nutze front-edit zum direkten bearbeiten der seiten - der seitenbaum interssiert mich fast nicht mehr!

außerdem - "langsam" macht den seitenbaum erst die Javascript-spielerein (drag&dorp..usw)

und wenn die seite "in betrieb" ist hab ich das immer aus ->keine langsammer pagetree

mfg martin

[Ralf Hertsch]

Ich kann mich dem allgemeinen Tenor nur anschließen, habe 2 Installationen die um bzw. über 500 Seiten haben bei beiden gibt es Frontend überhaupt keine Einschränkungen durch die höhere Seitenzahl.

Im Backend macht es sich allerdings deutlich bemerkbar, das Nadelöhr ist hier eindeutig der Pagetree, Caching hilft hierbei überhaupt nicht (macht sich nur im Frontend bemerkbar). Der Aufbau der Anzeige erfolgt träge ist aber (noch) im Schmerzbereich. Die Variante Frontend-Edit und ausgeschaltetes Drag & Drop im Pagetree ist hier für uns keine Lösung, weil bei beiden Installationen eher neue Artikel dazu kommen und bestehende Artikel verschoben werden - bestehende Artikel werden eher selten geändert.

Die Performance im Backend ließe sich deutlich verbessern, wenn die Einstellungen von JavaScript Admin Gruppenabhängig wären und - noch stärker - wenn Redakteure ausschließlich die Seiten angezeigt bekämen, die sie bearbeiten dürfen - im ungünstigsten Fall darf hier ein Redakteur nur eine einzige Seite bearbeiten und keine neuen Seiten anlegen, bekommt aber trotzdem den ganzen Pagetree präsentiert (bei AMASP ist die Situation ähnlich). Der Verzicht würde auch die Übersicht für den Einzelnen verbessern 

Gruß
Ralf

[doc]

Hi,

neben der Beschränkung des Pagetrees auf Seiten die bearbeitet werden dürfen, könnte man auch die Anzeige bei mehrsprachigen Seiten auf einen Ast (z.B. DE, EN, XX) beschränken.

Hatte dies mal für einen Kunden realisiert, der so 100 Seiten in 4 verschiedenen Sprachen hatte. Als Default wurde der Ast der eingestellten Benutzersprache oder ein Default angzeigt. Umschaltung auf einen anderen Ast erfolgt über Flaggensymbole oder "Alle anzeigen". Dürfte auch das Backend der WB-Hilfeseite um einiges "beschleunigen"  

Doc