Das vernünftig ist relativ - verarbeiten können alle Versionen mehr als 100 Seiten.Welche Version ist denn die letzte, die mit erheblich mehr als 100 Seiten noch vernünftig zurecht kommt?
Theoretisch ist die Kapazität derart, dass du die ganze Bibel plus altem Testament darin packen kannst.
Die Frage ist die, welche Inhalte die Seiten haben (z.B. Verschachtelung mit News oder RSS-Feed und ähnliche Einlagen wie Kalender etc.) und welche Performance man erwartet.
Die bisherige Systematik läuft leider darauf hinaus, dass man monatlich teils erheblich mehr Geld abdrücken muss, für einen Webspace das eine gute oder gar hohe Performance auf der Besucherseite bei hohem Seitenvolumen und komplexen Verschachtelungen der Inhalte bringt.
Ich kenne diese CMS seit einer frühen 0,6 er Version. Es wurde stets angebaut aber nie war man besorgt um die Perfomance.
Eine normale Domain hat natürlich auch ihre Grenzen, da die ganze Hardwwarestruktur mit vielen anderen geteilt werden muss.
Deswegen ist es ein Zwang den Resourceneinsatz genau zu überprüfen und zu minimieren.
Diese Beta liegt bei einer frischen Installation schon bei rund 7 MB, die normale Scriptgröße bei der überwiegenden Domainmehrheit liegt bei 8 MB und damit kratzt man schon an der bei vielen machbaren Grenze.
Aber Speicher sparen ist auch nur ein Ding.
Wenn z.B. eine hier so gut wie überall verwendete Klasse bei 390 Seiten eine einzelne Unterfunktion - Funktion 62790 mal aufruft und dabei genauso häufig ein dynamisches Objekt anlegt, dann erklärt sich der hohe Speicherverbruach und die gemütliche Geschwindigkeit. Diesen einen Punkt habe ich Wishy angezeigt, der hat es verstanden und wird daran etwas ändern - aber - ähnliche Mechanismen gibt es mehrere - die verballern Speicher und Zeit und eigentlich für nichts.
Das sind eigentlich schwerwiegende Programmierfehler mit denen jeder Informatiker auf der Uni seine Scheine nicht bekommen würde.
Hier erklärt sich das aus dem anscheinend überraschenden Erfolg der CMS und den Zwang, stets etwas mehr anbieten zu müssen.
Leistung zu erreichen ist 1. eine Konzeptfrage und 2. eine stetig kitische Betrachtungsweise des Konzepzts und der Umsetzung in den kleinsten Bestandteilen. Ja selbst ein unnötiges Include eine externen PHP - Datei kann für den Betrachter 0,01 .. 0,03 Sekunden an Performanceverlust bringen.
So führen viele kleine Schritte zu einem hohen Gesanmtverlust.
Was bei dieser CMS vollständig fehlt ist eine Qualitätssicherung und das Bemühen unter allen Umständen die optimale Codierung zu erreichen.
Und, es fehlen die schnellen Entscheidungen - z.B. ist der Einsatz der aktuellen Smayrtversion und der eigentlich dafür seit X Versionen vorgesehenen Verzeichnisstruktur ist innerhalb von Minuten machbar.
Das Konzept ist in Teilen ebenfalls nicht optimal.
Aus meiner Erfahrung sind folgende Dinge wichtig:
1. vollständig getrennter Code für die Besucherseite und der Administratorseite - es ist unmöglich, den Speicher für Besucher mit Inhalten aus dem Admin-Beriech zu verstopfen und die Perfomance zu senken.
2. Einsatz von fremden Libs nur wenn notwendig in der Orignalversion (z.B. Adodb , Smarty), nie in einer gehackten - das ermöglicht dann sogar einem User in Selbsthilfe ein Update der Libs oder eine Erweiterung (Adodb kann erheblich mehr als das was die Minimallieferung mit der CMS erlaubt).
3. Konsequenter Einsatz von Smarty in allen Teilen - erleichtert erheblich die Wartung - wenn ich sehe, wie man sich die Finger verbogen hat um z.B. das Inhaltslisting oder das Adminmenü herzustellen ....
Man muss Entscheidungen treffen und nicht lange zaudern. Wenn etwa Adodb sich von der Stufe wertvoll auf sinnlos bewegt (weil kein Schwein Postgresql einsetzt), dann schmeisst man es in den Fluss und schleppt es nicht weiter mit.
Und das ist der eigentliche Grund warum sich diese CMS weit hinter ihren eigentlichen Möglichkeiten befindet.
Ich habe selbst 2 komplette CMS geschrieben und beide komplett verkauft. Die letzte hatte auf einem als langsam zu bezeichnenden normalen Webserver einen Zeitbedarf von 0,001 bis .. 0,014 Sekunden um eine Seite von 5000 aufbereiten zu können. Das wird diese CMS wegen völlig anderen Konzeptes nie erreichen, ich halte aber einen Wert von 0,1 Sekunden OHNE eaccellerator durchaus erreichbar und damit wäre diese CMS auch im Zusammenhang mit der einfachen Bedienbarkeit einer der Renner überhaupt und kaum noch von anderen zu schlagen.
