WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

Warum ist WebsiteBaker eigentlich so schnell?

(1/3) > >>

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.  :evil:

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 :-D)

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:

--- Quote from: Waldschwein on September 25, 2009, 10:44:36 AM ---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.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page