CONTENIDO Forum

phpchris hat geschrieben:Auch die größeren Projekte die mit Contenido laufen sind sehr performant.

Die da wären...?

i-fekt hat geschrieben:Ich gebs auf...

wenn du mit der puren, ignoraten Einstellung "Contenido braucht ein Caching" an die Sache rangehst, wird das auch nichts. Oder glaubst du mir nicht, daß wir als Entwickler uns da nicht schon stundenlang über Konzepte beraten haben und im Endeffekt festgestellt haben, daß es keinen Sinn macht?

Du wirst es wohl nur dann verstehen, wenn du selbst versuchst, so etwas zu implementieren und die Internas von Contenido untersuchst. Vorher nicht.

Ein Feature ohne Grund zu wollen ist doch schon etwas seltsam. Wenn du wirklich ein Performanceproblem bei irgendeiner Website hast, dann lass es uns wissen, wir werden dir sicherlich so gut wie es geht helfen, das Nadelöhr zu finden. Aber mit der Aussage "Ein Caching wäre 'ne tolle Sache, Typo3 und andere CMS haben das ja auch " alleine wird da nichts passieren, denn dazu sind die Systeme einfach zu unterschiedlich.

Ich will nur das versuchen euch nahezulegen, was ich für durchaus sinnvoll halte. Ich habe keine Performance Probleme, aber die Seite ist auch nicht unbedingt so besucht wie manch größere.

Bei den Absätzen analog conFlakes bin ich ja auch gescheitert, wenngleich ich fest überzeugt bin, dass das in ein CMS riengehört und über kurz oder lang auch in Contenido kommen wird. Das sind ja nicht alles Wünsche die ich aus der Luft greife, sondern Dinge, die ich täglich sehe weil ich selbst mit CMS arbeite. Ich sehe auch wie unser CMS Anbieter sich an anderen Systemen Dinge abschaut, die wichtig und sinnvoll sind. So eben die Absatzformate bei Typo3, die es vorher auch nicht gab aber wichtig waren um Konkurrenzfähig zu sein, denn das sind Argumente die einen zu einem anderen CMS wandern lassen.

Das mit conFlakes wurde ja ausreichend diskutiert und auch da kamen wir zu dem Schluß, daß Typo3 eben auch hier ein anderes Konzept fährt als Contenido. Solche Entscheidungen musst du akzeptieren, Contendo kommt eben nicht als all-in-one-Package, sondern als lightweight-CMS, welches einfach erweitert werden kann. Dieses Konzept wird in Zukunft auch ausgebaut werden. Ich (bzw die anderen, die noch Mitspracherecht bei Contenido haben) treffen die Entscheidungen ja nicht aus dem Bauch heraus, sondern es gibt gute Gründe für die jeweiligen Entscheidungen.

Auch bei deinem Caching gibt es eben überhaupt gar keinen Grund, so etwas zu implementieren, was den Modulentwicklern und Redakteuren nichts bringt, weil es für sie mehr Aufwand bedeutet und für uns als Contenido-Entwickler ebenso - und das bei einem nicht oder nur gering messbaren Geschwindigkeitszuwachses. Deshalb auch meine Bitte, mir eine Website mit Contenido zu zeigen, die wirklich langsam ist, damit wir die Ursache beheben können! Auf der anderen Seite kannst du bei deiner Website TV Stetten einfach mal das Frontend-Debugging aktivieren und dir ansehen, wieviel (bzw wiewenig) Rechenzeit pro Seitenaufruf benötigt wird. Dann kannst du dir einfach errechnen, wieviele Contenido-Requests pro Sekunde möglich sind.

Ich habe auch schon sehr oft bei anderen OpenSource-Projekten Ideen angebracht, die im Endeffekt nicht umgesetzt wurden, und auch hier habe ich die Entscheidung ohne größeres Murren akzeptiert, weil die Erklärungen Schlüssig waren.

Ich akzeptiere es, aber ich verstehe es nicht. Mein Ziel ist die Verbesserung des CMS, sonst würde ich mich nicht so dafür engagieren.

Ich habe gute Gründe vorgebracht, warum diese Entscheidung steht. Ich werde mich nicht mehr dazu äussern.

i-fekt hat geschrieben:

phpchris hat geschrieben:Auch die größeren Projekte die mit Contenido laufen sind sehr performant.

Die da wären...?

Schau mal hier: http://www.contenido.org/forum/viewtopi ... cherzahlen

ich hab mich jetzt mal etwas näher mit einem wirklich simplen cache mechanismus gespielt...

der einzige unterschied zu normalen php ist einfach nur der
ich hab das jetzt mal getestet funktioniert ganz gut...

es gibt natürlich ein paar einschränkungen bei dieser ersten variante
momentan ist nur jedes gecachte element in sich geschlossen alleine lauffähig... (läßt sich aber lösen)

theoretisch ist damit durchaus möglich etwas wie dynamische CMS_HTML[$i] umzusetzen...

aussehen würde das in etwa so
hauptproblem ohne contenido interne kenntnisse ist es somit ziemlich schwer überhaupt selbst ein lauffähiges modul zu schreiben...

es stehen in diesen in sich selbst geschlossenen elementen an sich nur $lang, $client, $idart, $idcat, $idcatart zur verfügung...
zusätzlich hab ich was eingebaut sodas die module selbst erkennen ob sie gecached ausgeführt werden oder nicht...
und man müsste höllisch aufpassen nicht contenido eigene variablen zu eleminieren...

somit ist es glaube ich momentan noch keine gut idee das code fragment zu veröffentlichen...

zeitaufwand das komplett fertig umzusetzen, so das man das ebenfalls im kompletten generierten con_code nutzen kann, wird sich in etwa auf 30 stunden belaufen... (als test hab ich das ganze momentan nur auf module beschränkt)

anpassungen am contenido core code müssten glaube ich nur bei 2-3 dateien vorgenommen werden....

ich hab noch ein paar tests betreffend speed gemacht...

die erstmalige generierung des con_code benötigt in etwa um 60-80% mehr zeit als normal... (kommt natürlich auf die module an...)

jeder weitere seitenaufruf ist ca um 30% pro seite schneller... zumindestens in meinem fall...

dann hast du aber auch hier das Problem, daß Module nicht mehr einfach so geschrieben werden können, oder?

Auch die 30% müssten dann vom entsprechenden Modul abhängig sein, richtig?

timo hat geschrieben:dann hast du aber auch hier das Problem, daß Module nicht mehr einfach so geschrieben werden können, oder?

na ja das einfach zu beschreiben... ich werd's mal versuchen...

im prinzip ist das ganze eine vorevaluierung von gewissen passagen des codes... der output ist dann entweder html oder generiertes php...
je nachdem was das modul halt erzeugen soll... (in meinem fall ist das generiertes php)
ich hab das ganze momentan in eine eigene funktion ausgelagert, die einige globale variablen für diesen vorevaluierten code zur verfügung stellt.
nach einigen tests hat sich folgende konstellation als ganz dienlich erwiesen...
$idcat, $idart, $idcatart, $idartlang, $lang, $client, $cfg, $cfgClient, $edit, $sess, $perm, $auth, $encoding und eine eigene $db instanz...
zusätzlich hab ich eine $cache variable nur für diese module zur verfügung... (mit dem kann das modul selbst überprüfen ob es gecached ist oder nicht)

wenn man nur etwas wie
benötigt, ist der ganze aufwand natürlich für die katz..

eine kombination aus bisherigen php code und code der gecached wurde ist natürlich auch möglich

timo hat geschrieben:Auch die 30% müssten dann vom entsprechenden Modul abhängig sein, richtig?

die zeitersparnis ergibt sich größtenteils nur bei db abfragen, array schleifen etc... die immer wieder gleich sind...

um den code komplett neu zu erzeugen reicht ein einfaches &force=1 bei der url, bzw man speichert einen content, ändert das template, ändert den modul code... oder das layout (also so wie bisher..., das ganze ist gekoppelt mit conGenerateCodeForXXX )

ich hab das ganze momentan bereits auf alle module und layout ausgedehnt... und arbeite da momentan noch mit einem regulären ausdrücken... vermutlich ist es deshalb zum teil noch so langsam...

verwendung von CMS_VALUE werten funkt problemlos
galerien laufen ebenso einwandfrei... (man darf sich dann halt nicht erwarten das dinge wie automatisches scannen von verzeichnissen ebenso bei jedem aufruf funktioniert)

gewisse kleinigkeiten werden bei dieser arbeitsweise mit dem code nicht funktionieren...
zb auswertung von $_GET,$_POST,$_REQUEST werten (wäre ja schwachsinnig, das bei gecached code zu versuchen)
man kann an sich nur mit den obrig vorgegebenen variablen arbeiten...

tja wie gesagt ich steht da erst ziemlich am anfang

ich hab jetzt alle schleifen und alle pregs rausgenommen...
ist ja nahezu pervers wie einfach das funktioniert...

hab das nochmal mit den zeiten durchgespielt...
mit erzeugung gecachter teile für die con_code brauch ich bei 10 versuchen nur um 2% länger als ohne gecachte version
auf der anderen seite ist das schlussendliche ausführen der con_code aber um fast 19% schneller...

das mit den con_type in schleifen ist halt ein netter bonus der sich da ergibt...

mittlerweile ist es auch egal wie viele teile eines moduls gecached sind.. bzw wenn nicht sogar ganze teile des layouts

ich werd das mal etwas ausgiebiger bei einem neuen projekt testen...

ja wäre gut - das halte ich für sinnvoller als den kompletten Moduloutput zu cachen

damit liegt es wirklich in der Hand des Entwicklers

ich werd noch etwas testen und poste den code dann im contenido developer teil des forums...