Erwiterte Modulconfiguration Einstellungen

[mistral]

Hallo zusammen

Zur Zeit kann in den Modulen für die Ausgabe nur ein Code eingegeben werden. Bei Modulen, welche mit Modulwiederholungen arbeiten (MrList / ContentFlex/ ...) bedeutet das, dass Funktionen und Klassen die nur einmal definiert werden müssten so oft im Code aufgeführt werden wie die Anzahl der Wiederholungen. Dies führt zu einem viel zu grossen Ressourcenverbrauch, wenn viele Wiederholungen verwendet werden.

Ich schlage vor das die Module um 2 Output-Bereiche erweitert werden. Einen welcher vor der Ersten Wiederholungen ausgeführt wird und ein Bereich der nach der letzten Wiederholung ausgeführt wird. Aus meiner Sicht könne so die Module einiges Einfacher aufgebaut werden und der Speicherverbrauch und die Geschwindigkeit kann deutlich verbessert werden.
Als Anwendungsbeispiel könnte im ersten Bereich eine Klasse definiert und instanziert werden. In jeder Wiederholung kann mit der Klasse gearbeitet werden, z.B. Daten abgelegt werden. Im letzte Bereich kann mit den Daten in der Klasse z.B. eine Seiten-Navigation ausgegeben werden.


Folgendes Beispiel soll den Nutzen aufzeigen:

Bei MrList gibt es einen Bereich im Modul welcher nur bei der letzten Wiederholung benötigt wird. Wenn ich diesen Teil des Moduls in eine Datei ausgelagere und nur bei der letzte Wiederholung einbinde (dies entspricht der Simulation des FR), kommt der Speicherverbrauch überproportional zurück.

Ich habe weniger als 19kByte von MrList in eine externe Datei verlagert. Bei 10 Wiederholungen (Einträgen) von Mr List hatte ich folgenden Speicherverbrauch für die gesamte Seite:

In Datei ausgelagert und erster Aufruf (nichts im Cache)
executiontime: ( 0.4731)
memory allocated: ( 4598k)
peak of memory allocated: ( 6507k)

Original und erster Aufruf (nichts im Cache)
executiontime: ( 0.5689)
memory allocated: ( 5604k)
peak of memory allocated: ( 8282k)

In Datei ausgelagert und alles im Cache
executiontime: ( 0.1420)
memory allocated: ( 3532k)
peak of memory allocated: ( 5272k)

Original und alles im Cache
executiontime: ( 0.1585)
memory allocated: ( 4147k)
peak of memory allocated: ( 6333k)

Das zeigt, dass ein Auslagern von 19k bei 10 Wiederholungen nicht nur die Erwarteten 190k weniger Speicher verbraucht, sondern 1800k. Also 100k weniger Speicherverbrauch pro Wiederholung. Auch die Geschwindigkeit steigt um 10-20%. Bei noch mehr Wiederholungen ist der Geschwindigkeitszuwachs noch grösser

Gruss
Mistral

[STam]

Hi mistral,

das kann ich nur bestätigen und grundsätzlich ist der Gedanke auch nicht der schlechteste.
Aber damit wird wieder mehr in die dB verlagert

Ich denke aber SF bietet auch so schon genügend Möglichkeiten für Entwickler es zu erweitern oder anzupassen.
Vielleicht sollte man der alten Definition der Module und Plugins abweichen und diese neu aufstellen.
Deine Tests zeigen doch wunderbar wie viel besser es mit ausgelagertem Code funktioniert.
Warum also nicht Code in extra Dateien auslagern und diese dem Modul und auch anderen zur Verfügung stellen?
Das wäre nämlich ein Nachteil der Lösung mit den erweiterten Modulen, alles wandert in die dB und muss
dort für jedes Modul wieder vielfach abgelegt werden, der Speicherverbrauch und die Zugriffe in der dB wachsen
dann ins unermäßliche, eher eine gegenteilige Entwicklung.

Ich tendiere viel eher dazu eine Art Modul API anzubieten (Pfad: '/API/MODULE/')
wo jedes Modul Code ablegen kann der dann auch von anderen Modulen/Entwickler genutzt werden kann.

Schau dir mal das Beispiel meines OpenID-Plugins an, dort wird die SF-API erweitert (sogar überschrieben)
nur um bestimmte Funktionalität aus dem Modul rauszuhalten.

Zurzeit lässt sich jedes Modul ja auch über ein Plugin installieren und das Plugin würde dann
(auch ganz ohne Backend-Menüpunkt) die benötigten Klassen/API an SF weiterreichen.
Das ist (noch) nicht der sauberste weg, aber es funktioniert (und hat Charme).

In Zukunft sollte ein Modul das auch alleine können, dass wäre eine Änderung des Modulformats
die sich nur auf die Installation bezieht und würde weit mehr Vorteile mit sich bringen als
die Lösung die du vorgeschlagen hast. Ich denke mit deiner Lösung wird das ganze nur zu
eingeengt und nicht wirklich gelöst.

Es gibt zwar noch einige Bugs in der API Implementation und auch im ganzen ist SF noch
nicht soweit umgestellt das die API voll genutzt wird, dennoch denke ich das das der
weg ist der SF zukünftig für Änderungen und Erweiterungen am besten fit macht.

... das waren nur Denkanstöße... schön das sich mal jemand Gedanken macht hier

Gruß

[smail]

Offtopic

Apropos API: gibts dazu irgendwie eine Dokumentation?
Ok, ok, ich kann die Antwort schon raten: wohl eher nicht

Wie kommt man dann man besten rein in das Thema?


Gruß
Jan

[Tiggr]

Hiho!

Jau, die Idee mit dem aufgeteilten Code find ich gut! Initialisierungs- und Abschlusscode für Module sozusagen. Das würde ich sofort unterstützen!

Langfristig würde ich auch zustimmen, dass zu viel in der DB gehalten wird. Datenbanken sind erst bei wirklich großen Datenmengen, aus denen man nach komplexen Abfragen raussucht schneller als andere Möglichkeiten.

Der ideale Kandidat um in das Dateisystem zu wandern wäre sicher die cms_code-Tabelle, aber ob man da den Unterschied merkt?

Eher geht es darum, die Zahl der DB-Abfragen generell zu senken. Ein Beispiel für sowas ist sicher Vanilla von Lussumo, da wird zum Beispiel die ganze Konfiguration in PHP-Files gehalten, weil wirklich jede Seite ja Konfigdaten braucht, selbst wenn es nur der Login-Screen ist, der sonst nichts mit der DB am Hut hat.

Der nächste Optimierungspunkt ist sicher der Speicherverbrauch, der war bei DiDi schon eine mittlere Katastrophe, bei Sefrengo macht man sich da schon Gedanken. Die Dreiteilung des Modulcodes wäre ein erster Schritt in diese Richtung und sicher ein richtiger Schritt. Ob man den Code dann in der DB hält oder im Filesystem, ist dann eine zweite Frage...

Mein Vorschlag zur Güte wäre: Erstmal den Code in die Datenbank auslagern, ich glaube nicht, dass das zu mehr Abfragen führt. 'select * from' liefert alle 3 Teile auf einmal zurück! Wer dann lieber auf's Filesystem ausweichen will - eine Stelle mit Funktionsbibliotheken wäre sicher toll (API?) - der schreibt da halt ein include rein, und holt sich seinen Code wieder aus dem Filesystem!

Filesystem hätte auch noch den Charme, das man seinen Code sauber aufteilen kann, verschiedene Dateien anlegen kann, und somit auch komplexere Module angehen kann.

Was mir besonder gefällt an der Idee ist, das ich keinen Grund sehen, dass das irgendwo mit schon bestehenden Modulen bricht! Alte Module füllen halt nur den wiederholten Code aus, verschwenden weiter Speicher und Rechenzeit, aber sie laufen ohne Änderung weiter!

Von mir gibt es ein +1 für Mistrals Vorschlag!

Tschüss
Tiggr

Der Beitrag wurde von Tiggr bearbeitet: Sun. 4. March 2007, 01:25

[gunwalt]

Grundsätzlich ist Mistrals Idee sehr gut. Problematisch escheint mir allerdings die Updatefähigkeit, bitte korrigieren, wenn ich es nicht richtig verstanden habe. Also Updatefähigkeit, das zum Modul immer noch irgendwelche Systemdateien mit hochgeladen werden müssen..

Wäre es deshalb nicht möglich zweigleisig zu fahren, nämlich zu unterscheiden zwischen Standardmodulen, die eben diese Möglichkleiten haben und damit arbeiten und anderen, die der Einfachheit der Entwicklung den bisherigen Weg gehen?

[Tiggr]

Hallo!

Problematisch escheint mir allerdings die Updatefähigkeit, bitte korrigieren, wenn ich es nicht richtig verstanden habe. Also Updatefähigkeit, das zum Modul immer noch irgendwelche Systemdateien mit hochgeladen werden müssen..

Glaub ich eigentlich nicht so!

Mistral schlägt ja nur vor, das es zwei neu Felder im Modulbereich gibt, also zwei neue Felder in der DB, beim Upload bleibt also alles beim alten.

STam schlägt wiederrum vor, dass Module noch immer eine Datei sind, aber die verschiedenen Teile im Filesystem abgelegt werden, um auch von anderen Modulen nutzbar zu sein. Also dass sich das System drum kümmert alles da abzulegen, wo es hin soll! Das ist IMHO eine gute Idee, aber wohl eher was für die 2.0.

Tschüss
Tiggr

[STam]

STam schlägt wiederrum vor, dass Module noch immer eine Datei sind

...
Sorry das war vieleicht mißvertändlich, mein Vorschlag geht mitnichten davon aus das Module immer
im Dateisystem abgelegt werden.

Präziser:
Nach meinem Vorschlag bleibt ein Modul so wie es ist, in der dB!
Grundsätzlich hat ein Modul 2 Daseinsformen:
- als Datei modulname.cmsmod
- gespeichert in der dB

Ich möchte nun die Dateiform (Xml) ändern.
Und zwar so das ein Modul bei der installation in SF
der API sagt: '... hey hey ich hab hier ne nette Library für dich,
binde die doch mal als MODULE_MeinModulApi ein'
Und fertig ist, die API übernimmt die Erweiterung und diese kann
dann ganz einfach über die SF-API aufgerufen.
Um das noch besser zu spezifizieren; ich übernehme mistrals Idee,
allerdings sehe ich nicht die notwendigkeit die dB zu erweitern und
den zusätzlichen Code dort abzulegen, sondern ich schlage vor nur
diesen extra Codeteil als Bestandteil der API in SF einzubinden.

... schwieriges Thema, vieleicht ist es ja jetzt verständlicher

Gruß

[MaZderMind]

Hi
Mein vorschlag für ein neues Modulformat wäre, das komplette Modul als eine einzige Klasse anzulegen. diese erbt von einer Modul-Mutterklasse und kann nach bedarf Funktionen wie open, close, showConfig, showOutput oder sowas überschreiben. Beim Upload eines in xml verpackten Modules schreibt SF den Inhalt in eine Datei, die den Namen der Repo-ID des Moduls hat (und damit eindeutig ist) in einen Zweig des Api. SF kann nun den API-Store benutzen um die Klasse zu cachen, die open- und close-Routinen nur einmal auszuführen und den Rest beliebig oft.
Man könnte diese Methode auch paralel zu den vorhandenen Modulen betreiben, in dem man im XML einfach einen weiteren Tag anlegt, der SF sagt nach welcher Methode das Modul zu behandeln ist.
Über diese Klasse könnten übrigens auch Install/Uninstall/Updatevorgänge laufen, wie das ja auch bei den Plugins schon ist.

Gruß, Peter