Vorstellung

TUM_IDP · Beitrag von **TUM_IDP** » Mi 21. Jan 2004, 16:57

Hallo allerseits!

Wir möchten uns an dieser Stelle vorstellen. Wir sind zwei Studenten der TU-München und machen derzeit eine Projektarbeit am Lehrstuhl für Betriebswirtschaftslehre mit Schwerpunkt Logistik. Der Lehrstuhl wird seine Webpräsenz in Kürze auf Contenido umstellen und möchte dafür noch einige Erweiterungen, die wir in Zusammenarbeit mit euch umsetzen sollen.

Konkret sind derzeit folgende Dinge geplant:

Statistiken
Ein Statistikmodul soll ausführliche Informationen über die Nutzung der Internetseiten liefern.

Workflow
Zum kontrollierten Veröffentlichen von neuen Beiträgen soll die Möglichkeit geboten werden diese vor der Publizierung in einer Vorschau zu begutachten.

Suchfunktion
Eine datenbankübergreifende Suchfunktion soll vom CMS aus in mehreren Lehrstuhldatenbanken suchen und die Suchergebnisse unterteilt in Kategorien anzeigen.

Statische Seiten
Zur Entlastung des Webservers sollen Webseiten nicht dynamisch vom CMS erzeugt werden, sondern wie statische HTML-Seiten aufgerufen werden. Dabei sollen auch die statischen Seiten ins CMS integriert sein.

Wir wären euch dankbar, wenn ihr uns sagen könntet, ob eine oder mehrere der oben genannten Punkte von euch geplant oder in irgend einer Weise bereits umgesetzt ist.

Es wäre uns auch eine große Hilfe, wenn ihr uns sagen könntet, für wie leicht oder schwer realisierbar ihr ein Feature haltet.

Vielen Dank erstmal und auf eine gute Zusammenarbeit.

Beitrag von **HerrB** » Do 22. Jan 2004, 08:27

So, so, mit uns. Bekommt man dann einen Abschluss?

Statistiken:
Vermutlich simpel, da Statistik bereits in Contenido integriert ist (und halt nur für die Webseite ausgegeben werden muss).

Workflow:
Stellt euch 4fb vermutlich kostenpflichtig zur Verfügung. Das ist ein Profi-Feature, wovon 4fb u.a. lebt...

Suchfunktion:
Innerhalb Contenido kein Problem (da gibt es ein gut funktionierendes Modul). Auf externe Datenbanken wird es Zeit kosten (da ihr euch mit der Art und Weise der Datenbank-Anbindung in Contenio vertraut machen und das dann für die anderen DB zusätzlich integrieren müsst -> PHP -> MySQL -> DB-Anbindung mit PHP...).

Statische Seiten
Das würden viele gern, siehe "Suchmaschinenfreundlichkeit von Contenido" und gilt m.E. als noch nicht gelöst (man konnte mod_rewrite verwenden, aber das führt nach meinem Verständnis noch immer zu Datenbankabfragen). Die Lösung würde alle interessieren.

Hope that helps.

Gruß
HerrB

TUM_IDP · Beitrag von **TUM_IDP** » Do 22. Jan 2004, 09:34

So, so, mit uns. Bekommt man dann einen Abschluss?

Nein, höchstens einen Abschuss.

Wir sollen das schon selber machen, aber hier und da braucht man doch schon mal Hilfe von Leuten, die das schon länger machen und sich besser auskennen.
Und wir bekommen dafür die Nebenfachprüfung im Hauptstudium, statt Vorlesungen.

Statistiken:
Vermutlich simpel, da Statistik bereits in Contenido integriert ist (und halt nur für die Webseite ausgegeben werden muss).

Müssen wir uns mal genauer anschauen und evtl. um unseren Bedarf erweitern.

Workflow:
Stellt euch 4fb vermutlich kostenpflichtig zur Verfügung. Das ist ein Profi-Feature, wovon 4fb u.a. lebt...

Ah so. Vielleicht gibt's dann bald eine kostenlose Lösung.

Suchfunktion:
Innerhalb Contenido kein Problem (da gibt es ein gut funktionierendes Modul). Auf externe Datenbanken wird es Zeit kosten (da ihr euch mit der Art und Weise der Datenbank-Anbindung in Contenio vertraut machen und das dann für die anderen DB zusätzlich integrieren müsst -> PHP -> MySQL -> DB-Anbindung mit PHP...).

Dass wir in den Innerein rumwühlen müssen, war schon eingeplant.

Statische Seiten
Das würden viele gern, siehe "Suchmaschinenfreundlichkeit von Contenido" und gilt m.E. als noch nicht gelöst (man konnte mod_rewrite verwenden, aber das führt nach meinem Verständnis noch immer zu Datenbankabfragen). Die Lösung würde alle interessieren.

Da werden wir uns dann auch mal Gedanken machen.

Hope that helps.

Sure, vielen Dank!

Gruß
Lev

timo · Beitrag von **timo** » Do 22. Jan 2004, 09:40

HerrB hat geschrieben: Statische Seiten
Das würden viele gern, siehe "Suchmaschinenfreundlichkeit von Contenido" und gilt m.E. als noch nicht gelöst (man konnte mod_rewrite verwenden, aber das führt nach meinem Verständnis noch immer zu Datenbankabfragen). Die Lösung würde alle interessieren.

Einwurf: mod_rewrite funktioniert, und ob Datenbankabfragen oder nicht gemacht werden, das ist dem Herrn Google relativ egal

. Wichtig ist auch, daß z.b. die robots.txt entsprechende Werte enthält und daß solche komischen Weiterleitungsseiten mit http-meta-equivs nicht gemacht werden.

Beitrag von **HerrB** » Do 22. Jan 2004, 22:22

Einwurf: mod_rewrite funktioniert, und ob Datenbankabfragen oder nicht gemacht werden, das ist dem Herrn Google relativ egal

Schon klar, nur die Damen und Herren wollten die Belastung ihres Webservers reduzieren (und nicht den von Google...). Und da mod_rewrite meines Unwissens nach nur die äußere Darstellung ändert, würde ihnen das nix nützen...

Gruß
HerrB

TUM_IDP · Beitrag von **TUM_IDP** » Do 22. Jan 2004, 23:20

Schon klar, nur die Damen und Herren wollten die Belastung ihres Webservers reduzieren (und nicht den von Google...). Und da mod_rewrite meines Unwissens nach nur die äußere Darstellung ändert, würde ihnen das nix nützen...

Stimmt! Habe mir dazu folgendes überlegt:
Durch ein zusätzliches Flag kann bei jeder Seite, außer bei wirklich dynamisch generierten, angegeben werden, ob diese statisch sein sollen. Wenn eine Seite als statisch markiert oder erstellt wird, wird ihr dynamisch generierter Inhalt einmal in eine statische HTML-Datei geleitet. Dabei werden alle Links entsprechend einer Zuweisungstabelle angepasst. So dass die Links in der statischen Seite weiterhin alle Inhalte des CMS aufrufen können, aber mit Berücksichtigung der anderen statischen Seiten. Man kann dann entweder die statischen Links aufrufen oder den dynamischen, wenn man die URL kennt.

In wie weit das realisierbar ist, wird sich zeigen.

timo · Beitrag von **timo** » Fr 23. Jan 2004, 08:45

HerrB hat geschrieben:
Schon klar, nur die Damen und Herren wollten die Belastung ihres Webservers reduzieren (und nicht den von Google...). Und da mod_rewrite meines Unwissens nach nur die äußere Darstellung ändert, würde ihnen das nix nützen...

Achso, ich hatte das jetzt mit Google an sich in Verbindung gebracht. Problematisch ist, daß man nicht weiß, wann ein Modul anderen Output zurückliefert (pro Seitenaufruf? pro Request? pro Seite?). Es gibt zwar schon ein paar Ansätze hier im Haus, aber die sind leider noch nicht ausgearbeitet, aber soviel ist sicher:

Ohne Datenbankabfragen wird man nicht weit kommen. Der Trick ist daher, wie man die Laufzeit des Frontends verringern kann - beispielsweise mit Flags an Modulen, die der Engine verraten, wann ein Modul seinen Output ändert, um diesen dann zu cachen. Der Cache müßte aber trotzdem (zumindest im ersten Schritt) in die DB - so etwas auf dem Filesystem zu verwalten ist ein Meisterwerk für sich.

log2e · Beitrag von **log2e** » Di 13. Apr 2004, 10:54

Habe mir dazu folgendes überlegt:
Durch ein zusätzliches Flag kann bei jeder Seite, außer bei wirklich dynamisch generierten, angegeben werden, ob diese statisch sein sollen. Wenn eine Seite als statisch markiert oder erstellt wird, wird ihr dynamisch generierter Inhalt einmal in eine statische HTML-Datei geleitet. Dabei werden alle Links entsprechend einer Zuweisungstabelle angepasst. So dass die Links in der statischen Seite weiterhin alle Inhalte des CMS aufrufen können, aber mit Berücksichtigung der anderen statischen Seiten. Man kann dann entweder die statischen Links aufrufen oder den dynamischen, wenn man die URL kennt.

In wie weit das realisierbar ist, wird sich zeigen.

Sorry, dass ich hier einen Thread vom Januar aufwärme. Aber der Vorschlag klingt gut - ist dieser Ansatz in der Zwischenzeit weiter verfolgt worden?

- Stefan

TUM_IDP · Beitrag von **TUM_IDP** » Di 13. Apr 2004, 11:07

Sorry, dass ich hier einen Thread vom Januar aufwärme. Aber der Vorschlag klingt gut - ist dieser Ansatz in der Zwischenzeit weiter verfolgt worden?

Hallo!

Wir sind noch nicht so weit. Darum werden wir uns wohl erst im Juli kümmern. Wir haben uns aber schon ein paar Gedanken gemacht. Ein Problem gibt es allerdings, das schon weiter oben angesprochen wurde. Angenommen man hat jetzt eine komplett statische HTML-Seite. Wie verhält es sich dann mit den Modulen, die u. U. Datenbankzugriffe benötigen? Darüber werden wir nochmal nachdenken müssen. Wir halten euch aber auf jeden Fall auf dem Laufenden, wenn wir soweit sind.

kummer · Beitrag von **kummer** » Fr 7. Mai 2004, 10:19

timo hat geschrieben:Ohne Datenbankabfragen wird man nicht weit kommen. Der Trick ist daher, wie man die Laufzeit des Frontends verringern kann - beispielsweise mit Flags an Modulen, die der Engine verraten, wann ein Modul seinen Output ändert, um diesen dann zu cachen. Der Cache müßte aber trotzdem (zumindest im ersten Schritt) in die DB - so etwas auf dem Filesystem zu verwalten ist ein Meisterwerk für sich.

ist das wirklich so schwierig? ich könnte mir z.b. folgende lösung vorstellen:

(1) alle per get übertragenen parameter werden sortiert, aneinander gehängt und ein md5-hash gebildet. der resultierende string könnte als dateinamen dienen.

(2) liegt keine entsprechende datei im filesystem vor, muss die ausgabe dynamisch erfolgen. dabei könnte man über ein zeitfeld in den artikeleigenschaften festgelegt werden, wie lange eine seite gecached werden darf (oder eben gar nicht).

(3) wenn eine seite gecached wird, ist einfach zuoberst in der datei ein php-bereich einzufügen, der prüft, ob die seite noch aktuell ist (z.b. time() <= $cachezeitpunkt + $cachedauer). falls das nicht der fall ist, wird der rest der seite nicht zurückgegeben, sondern dynamisch erstellt (gemäss position 1).

auf diese weise wäre keinerlei datenbankzugriff erforderlich, wenn eine gecachte seite vorliegt, die noch nicht verfallen ist.

timo · Beitrag von **timo** » Fr 7. Mai 2004, 10:28

kummer hat geschrieben:ist das wirklich so schwierig? ich könnte mir z.b. folgende lösung vorstellen:

Ja, das ist komplizierter, als es erscheint. Eine Seite ist ja nicht statisch, sondern immer so dynamisch, wie dynamisch die Module sind. Und Contenido ist, bei einfacher betrachtungsweise, ein PHP-Code-Zusammenbastler.

kummer · Beitrag von **kummer** » Fr 7. Mai 2004, 10:39

timo hat geschrieben:Eine Seite ist ja nicht statisch, sondern immer so dynamisch, wie dynamisch die Module sind. Und Contenido ist, bei einfacher betrachtungsweise, ein PHP-Code-Zusammenbastler.

aber die entscheidung, ob und wie lange eine seite gecached werden soll, wird immer ein benutzer übernehmen müssen. seiten, die echten dynamischen inhalt aufweisen, wird man ohnehin nie cachen können (oder mindestens nicht für lange). und wenn man sie nur für einen sehr kurzen zeitraum cached, verliert man der performancegewinn gleich wieder für den aufwand, die seite immer wieder ins filesystem zu schreiben.

ich denke, letztlich wird man es immer dem autoren der seite überlassen müssen, die entscheidungen hinsichtlich des cachings (ob und wie lange) zu übernehmen. der muss halt dann wissen, was er macht.

ich schätze mal, wenn man zuerst herausfinden muss, was für module auf einer seite in verwendung sind und ob diese dynamisch sind und ob sich deren ausgabe seite dem letzten caching verändert hat, dann hat man durch das caching kaum mehr performance zu gewinnen.

timo · Beitrag von **timo** » Fr 7. Mai 2004, 10:42

kummer hat geschrieben:aber die entscheidung, ob und wie lange eine seite gecached werden soll, wird immer ein benutzer übernehmen müssen.

Sehe ich nicht ganz so. Eine Seite ist in Contenido mehr - ein Modul muß dann selbst sagen können, in welchem Grad es dynamisch ist (z.b. ist es Abhängig von der Kategorie, vom Content, oder ändert es immer seine Ausgabe). Ich würde sogar behaupten, daß statische Seiten und Contenido einfach nicht sonderlich viel Sinn machen.

Um wirklich statische Seiten zu generieren, und man darauf geachtet hat, daß die Module alle wirklich nicht dynamisch sind, kann man auch wget benutzen, um einen Abzug zu generieren.

kummer · Beitrag von **kummer** » Fr 7. Mai 2004, 10:54

auf den seiten unserer kunden gibt es immer haufenweise seiten, deren inhalt sich im besten fall alle paar monate einmal ändert. natürlich gibt es daneben immer auch seiten, die häufiger von aktualisierungen betroffen sind.

aber ich gebe dir gerne ein kleines beispiel. wir haben kürzlich eine anwendung entwickeln müssen, die eine abfrage auf eine oracle-datenbank machen musste. die abfrage läuft über ca. 20 joins (sehr ineffektiv). die suche läuft schneller, wenn sie auf einen snapshot gemacht wird. in der praxis bedeutet dies, dass änderungen, die an den daten vorgenommen worden sind, spätestens 12 stunden später sichtbar werden. für diesen fall ist das für uns völlig ausreichend und bringt einen performancegewinn von mehreren hundert prozent.

was ich meine ist folgendes: für eine seite muss doch der autor entscheiden können, mit welcher kadenz aktualsierungen für den enduser sichtbar sein müssen. wenn jemand nur einmal täglich aktualisierungen vornimmt, dürfte es für ihn in der regel unerheblich sein (mit ausnahme der suchseite), wenn die seiten 24 stunden gecached vorliegen.

ich gebe dir natürlich völlig recht: idealerweise würde ein caching auf modulebene vorgenommen. allerdings ist dabei der performancegewinn notwendigerweise kleiner, da vermutlich db-abfragen notwendig sind. mindestens muss das gecachte dokument seinerseits inkludierungen vornehmen.

timo · Beitrag von **timo** » Fr 7. Mai 2004, 11:52

kummer hat geschrieben:auf den seiten unserer kunden gibt es immer haufenweise seiten, deren inhalt sich im besten fall alle paar monate einmal ändert. natürlich gibt es daneben immer auch seiten, die häufiger von aktualisierungen betroffen sind.

Sind die Seiten dann so gut besucht, daß sich ein Caching lohnt? Wir haben bei einigen unserer Kunden um die 3000 Visits am Tag, mit täglich ca. 60.000 PI's. Der Server langweilt sich aber eher, als daß dort wirklich eine hohe Last erzeugt würde, wobei man bemerken muß, daß die Module dort auch wirklich sauber geschrieben und optimiert wurden.

was ich meine ist folgendes: für eine seite muss doch der autor entscheiden können, mit welcher kadenz aktualsierungen für den enduser sichtbar sein müssen. wenn jemand nur einmal täglich aktualisierungen vornimmt, dürfte es für ihn in der regel unerheblich sein (mit ausnahme der suchseite), wenn die seiten 24 stunden gecached vorliegen.

Ja, aber das kommt natürlich auf das Systemumfeld an. Wenn ein Autor z.b. entscheidet, daß sein Content (ich vermeide hier bewusst den Begriff "Seite") erst ca. 24 Stunden später erscheinen soll, dann ist das noch relativ einfach - aber der Autor hat im Regelfall keine Ahnung, welche Module dynamisch sind und welche nicht. Das einfachste Beispiel ist eine Login-Box, die auf jedem sichtbaren Artikel erscheint - schon bei dieser Anwendung ist mit der Statik schluß.

Aber: Die Artikel werden, zumindest vom "Modulzusammenbau" her, in der Tabelle con_code gespeichert, d.h. es sind nur maximal 5-6 SQL-Statements nötig, um einen Artikel "auszuführen". Wenn natürlich der Modulcode nicht optimal ist, dauert das entsprechend und es sind mehr Abfragen nötig, aber da gibt es ja immer Optimierungsmöglichkeiten.

Wenn du aber zu dem ganzen ein schlüssiges Konzept hast, immer her damit - von unserer Seite her haben wir aber auch schon mehrere Wochen Lösungsansätze entworfen und dann auch gleich wieder verworfen, weil es immer an derselben Stelle hing: Dynamik.