CMS Made Simple Forums

Irgendwie kann man nichts mehr auf dem topic von cyberman antworten.

Ich wollte noch hinzufügen, dass die Grenze der 0.11b6 unter Linux mit aktuellestem Apache, PHP und Mysql bei rund 100 Seiten liegt - vorausgesetzt, es wurden keine weiteren Moudle installiert und man muss sich an die 8 MB Grenze halten.

Wer Linux lokal hat, benötigt nur lampp von Apachefriend Version 1.50 und kann das selbst nachvollziehen.

Ich habe das unter Debian Sarge und unter Suse - Linux 9.1 und 10 probiert - Ergebnisse sind identisch.

Damit nähert sich diese CMS der Grenze ihrer Gebrauchsfähigkeit - da muss etwas getan werden !!

Hi Piratos,

Piratos wrote: Irgendwie kann man nichts mehr auf dem topic von cyberman antworten.

Stimmt. Ich hab das Thema geschlossen, weil ich mir den Schuh, den Westis mir hingestellt hat, nicht anziehen wollte .

Damit nähert sich diese CMS der Grenze ihrer Gebrauchsfähigkeit - da muss etwas getan werden !!

Wie immer vielen Dank für Deinen Bericht über die Testergebnisse. Ist halt nur schade, dass das bislang beim Dev-Team zu wenig Gehör fand.

Hmm, ist es eigentlich technisch möglich, den Speicherverbrauch der einzelnen Bereiche von CMSms festzustellen? Falls ja, könnte man sich die Speicherfresser nacheinander Stück für Stück vornehmen und dann entsprechende Verbesserungsvorschlag einsenden. Westis hat uns ja nochmals ausdrücklich zur Mitarbeit eingeladen.

Für einen CMS-Profi wie Dich dürfte das doch kein Problem sein, oder ?!

Ja, ich weiß, Dir fehlt der Schubs. Aber Flieden ist mir zu weit weg - ist ja nur so 'ne Idee ...

Ja sicher gibt es Möglichkeiten Speicherfresser im Detail zu ermitteln - aber es ist aufwendig und eigentlich eine Sache , die ein Entwickler von Anfang an im Auge behalten sollte damit sein Projekt kontinuierlich und innerhalb eines gesteckten Rahmens entwickelt wird.

Aber ich habe das Gefühl, dass man mögliche Ergebnisse bereits mehr oder weniger kennt und eigentlich davon nichts sehen und hören will.

Es könnte durchaus sein, dass dann eine komplette Neuprogrammierung erforderlich sein dürfte und nicht nur das - neue Strukturen sind dann erforderlich.
Ich denke da z.B. an die komplette Code - Trennung für den Besucherbereich und den Adminbereich.
Bis jetzt ist es ein Nuschelbereich der dem einen oder anderen Teil  mit Funktionesbereichen Speicher kostet, die z.B. der Besucher überhaupt nicht verwendet.

Was mir zu denken gibt, dass diese Probleme unter diversen Linux-Varianten auftreten, jedoch bislang nie unter Windows - da läuft die CMS tatsächlich auch mit ein paar tausend Testseiten.

Aber Windows scheint da auch leidensfähig wie ein alter Esel zu sein, während Linux in vielen Fällen hart durchgreift.

Auf der anderen Seite php-nuke und andere CMS - Systeme, die Adodb  (aber Original) verwenden laufen auf den beschriebenen Linuxservern und das auch mit reichlich Modulen - ebenso andere hammerharte System wie Mambo oder Xoops  - nur CMSMS nicht, was mir beweist, das es da eine Sache in der CMSMS geben muss, die nicht einwandfrei ist.

Ich habe z.B. eine gekaufte phplens - Version und arbeite damit unter Debian-Linux und Adodb an einer Browsergestützten Warenwirtschaft mit MS Access - Zugriff - die arbeitet unter meinen Linux-Versionen wunderbar und das bei rund 400.000 Datensätzen - was mir wieder mal beweist, das etwas and der CMSMS faul sein muss.

Auf der anderen Seite werden Dinge weit verschoben , obwohl sie in wenigen Minuten zu erledigen wären:

Since none of the fixes in smarty are security related and 0.11 is due out tomorrow, I'm going to roll this back to the 1.0 milestone.

(Hier geht es um die veraltete Smarty-Version und vor allem die seit längerem nicht mehr Smartykonforme Verzeichnisstruktur.)

Das deutet darauf hin, dass man offenbar etwas überfordert ist mit allem.

Unterm Strich glaube ich, dass es hier nichts bringen würde. Was soll man sich mehr abstrampeln als die Developer selbst es machen.

Piratos wrote: Auf der anderen Seite werden Dinge weit verschoben , obwohl sie in wenigen Minuten zu erledigen wären:

Since none of the fixes in smarty are security related and 0.11 is due out tomorrow, I'm going to roll this back to the 1.0 milestone.

(Hier geht es um die veraltete Smarty-Version und vor allem die seit längerem nicht mehr Smartykonforme Verzeichnisstruktur.)

Hatte ich auch schon mit Verwunderung gelesen. Wenn ich es allerdings richtig verstanden hab, soll CMSms 1.0 noch dieses Jahr released werden ("... next weeks ...")

Das deutet darauf hin, dass man offenbar etwas überfordert ist mit allem.

Als ich das gestern geäußert habe, war ich der Buhmann .

Was soll man sich mehr abstrampeln als die Developer selbst es machen.

Ähmm, um mit einem CMS zufriedenstellend arbeiten zu können ?

Na da scheint sich doch etwas zu regen - mal sehen was daraus wird - siehe die Postings zur beta6 - Ankündigung.

Es wird nun (wie ich es früher schon mehrfach gesagt habe) Adodb als Übeltäter vermutet.

Adodb selbst bietet ja zahlreiche Funktionen an um die Performance messen zu können und um auch zweifelhaft SQL - Abfragen entdecken zu können und manches mehr. Diese Funktionen bekomme ich aber mit der gehackten Version von Wishy nicht zum laufen - das Kopieren der fehlenden Scriptteile und die Initalisierung in der CMS funktionieren nicht -  werde demnächst mal die Originalversion nehmen.

Als ich das gestern geäußert habe, war ich der Buhmann

Nur keine Hemmungen - ich hau da drauf bis es qualmt.

Auf das cyberman drängelte - habe ich wishy mal den entscheidenden Tip gegeben, warum diese CMS so langsam ist und das hat gezündet. Vermutlich dürfte sich auch die Speicherthematik damit erledigt haben.

Ich bin gespannt auf die Umsetzung.

Siehste - so schnell kann man wishy glücklich machen .

Das Ziel sollte aber nicht die Lightversion sein sondern Mysql pur.

Wenn so gut wie keiner Postgresql benutzt wird ein Layersystem nicht benötigt.

Warum soll man Mysql in ein Layersystem beschreiben um letzten Endes doch die direkten Mysql - Befehle zu benutzen, genau das passiert nämlich damit und jetzt.

Ein Execute unter Mysql endet nach Durchlauf mehrerer Layerteile in ein banales

return mysql_query($sql,$this->_connectionID);

und dazu benötigt man Adodb nicht.

Bei Mysql direkt könnte man auf die Hälfte aler Tabellen verzichten, da Adodb als Layersystem Autoincrement nachbilden muss und nicht unterstützt.

Vorteil 2- 3 mal schneller und ein weiterer wesentlicher Vorteil ist die leichte Adapation von unzähligen Fremdmodulen in diese CMS und das ist viel interessanter.

Ich lass mich dann einfach mal überraschen ...

Zum Thema postgres fällt mir eine Aussage von wishy vom 11.September 2005 ein:

I get bug reports all the time from people who have issues with postgres.

Mein Lottoschein  - er wird das mit den vorhandenen Systemeinheiten machen was er kann, Konflikte mit Usern und Modulautoren scheuen wie der Teufel das Weihwasser und in etwa bleibt alles beim alten und zwar für lange Zeit.

Mal sehen ob ich einen 6 er habe.

Wenn der Tipp ein Treffer wird, verabschiede ich mich hier, denn dann bleibt bis auf einen guten Ansatz alles untere Mittelmäßigkeit und das ist aus meiner Sicht für mich selbst eine reine Zeitverschwendung.

Piratos wrote: Mein Lottoschein - er wird das mit den vorhandenen Systemeinheiten machen was er kann, Konflikte mit Usern und Modulautoren scheuen wie der Teufel das Weihwasser und in etwa bleibt alles beim alten und zwar für lange Zeit.

Welche Optionen (außer mySQL) wären denn für Dich ein Anreiz, dabei zu bleiben ?

Nach meiner Kenntnis soll die V2 ja komplett neu geschrieben werden ...

Für mich gibt es bei dieser CMS nur eine Entscheidung zu Gunsten von Mysql  - sqlite wäre mir zwar genauso Recht, aber php5.xx ist noch nicht so stark im Einsatz.

Adodb hat hier keinen Nutzen, da kaum jemand Postgresql verwendet.
In dem Moment ist das ein Speicherfresser und eine lahme Ente ohne gleichen.
Ich bin ansonsten nicht gegen Adodb , setze es ja sogar selbst ein mit phplens, aber nur weil ich in dem konkreten Fall einen Sinn sehe und nicht weil Adodb so schön ist.

Das Gegenstück wäre eine weitere Ausdehung auf andere Datenbanksysteme, aber dazu fehlt hier ganz klar die Kapazität - man wäre auf Gedeih und Verderb Addob ausgeliefert , in der guten Hoffnung, das alle Datenbanktreiber auch so funktionieren.

Wenn einer dabei bleibt, obwohl er das alles kennt, stellt seine Fähigkeit für mich in Frage, ein solches Projekt zum Erfolg führen zu können - da sehe ich nur wenige Zukunftsoptionen.

In dem Fall ist es für mich besser, mich anderen Dingen zuzuwenden und auch das ist kein Verlust für diese CMS, da ich bislang nur ein paar Kleinigkeiten gemacht habe.

Piratos wrote: Adodb hat hier keinen Nutzen, da kaum jemand Postgresql verwendet.
In dem Moment ist das ein Speicherfresser und eine lahme Ente ohne gleichen.

Naja, für die V1 sind IMHO eh alle Messen bereits gesungen.

Aber Wishy hatte ja die Möglichkeit einer anderen DB-Abstraktion angesprochen, ohne sich auf eine bestimmte festzulegen. Wie Du weist, bin ich (leider noch) kein Coder - wie gut bzw. schnell sind denn im Vergleich zu ADODB die möglichen Optionen (mir fällt da momentan nur PEAR::DB und PHPLib ein) ?

Evtl. könnte man mit einer schlanken, schnellen DB-Abstraktion (gibts so etwas ) einen goldenen Mittelweg finden.

Piratos wrote: Wenn einer dabei bleibt, obwohl er das alles kennt, stellt seine Fähigkeit für mich in Frage, ein solches Projekt zum Erfolg führen zu können - da sehe ich nur wenige Zukunftsoptionen.

Wenn ich sein Posting zu einem Deiner Hinweise richtig verstanden habe, scheint er ja häufiger mit anderen Sprachen als mit PHP zu programmieren.

Hmmm - wenn ich das alles so lese: Welche Version ist denn die letzte, die mit erheblich mehr als 100 Seiten noch vernünftig zurecht kommt?