CSS Bewertung (Seite 11)

seitenreport schrieb:


Ich halte allerdings den Begriff "Bytes/Sekunde" für etwas irreführend, denn die Ãœbertragung ist ja hier nicht fließend, sondern ein CMS generiert die Seite ja erst, bevor diese verschickt wird (hierher kommt ja der Zeitverlust).

Das ist nicht relevant da gzip über den Buffer erstellt wird ( ob_start("ob_gzhandler")

Das bedeutet alle Ausgaben werden dort gesammelt und dann mit gzhandler komprimiert und dann komplett abgedrückt.

Wo die Informationen her kommen ist auch für den Besucher ohne Relevanz.

Es ist die Entscheidung eines Betreibers ob er an der Software, der Hardware, an der Reduzierung des Volumens oder an allem etwas drehen will - für die Messung einer nackten Zeit ist das aber ohne Bedeutung.

Ich kann nur noch mal auf den Tipp mit der Reduzierung von memory_limit auf das notwendigste hinweisen, das bringt teils unglaubliche Verbesserungen - kann aber nicht jeder machen.

Bestätigt werden kann an dieser Stelle auch, dass eine per Hand erstellte "PHP-Homepage" bedeutend schneller ist, als ein TYPO3-Portal (Siehe Vergleich www.seitenreport.de mit www.matthias-glaessner.de, beide liegen auf dem selben Server). Diesen Unterschied bemerkt man z.B. gravierend beim normalen "Surfen" auf den beiden Seiten.

Vergessen darf man dabei natürlich nicht, dass ein TYPO3-Portal dafür erheblich sicherer (umfangreiche Sicherheitsroutinen) und erheblich leistungsfähiger ist.

Vielleicht kann aber das PowerCMS von piratos gerade hier eingreifen und im weiteren Entwicklungsstadium genau diesen wichtigen Mittelwert finden zwischen Sicherheit & Leistungsfähigkeit auf der einen Seite und Schnelligkeit auf der anderen Seite. Interessant wäre es z.B. wenn man im PowerCMS auch TYPO3- u.o. Joomla-Extensions verwenden könnte (da hier ein sehr breites Spektrum zur Verfügung steht).

piratos schrieb:

Das ist nicht relevant da gzip über den Buffer erstellt wird ( ob_start("ob_gzhandler")

Das bedeutet alle Ausgaben werden dort gesammelt und dann mit gzhandler komprimiert und dann komplett abgedrückt.

Naja, aber nur, wenn man die Komprimierung von php machen läßt. Und das ist auf gar keinen Fall eine gute idee. Da stimme ich unumwunden zu. Das sollte besser der apache übernehmen.

piratos schrieb:

Ich kann nur noch mal auf den Tipp mit der Reduzierung von memory_limit auf das notwendigste hinweisen, das bringt teils unglaubliche Verbesserungen - kann aber nicht jeder machen.

Seitenreport läuft auf 128 MB (PHP-)memory_limit, wobei es in TYPO3-Systemen bei weniger als 64 MB teils zu Problemen mit bestimmten Extensions bzw. deren Installation geben kann (z.B. EXT:phpmyadmin). Ein Zurückdrehen wird daher etwas schwierig. Hochdrehen ginge :wink:

Die Komprimierung wird immer vom Apache vorgenommen (z.B. mod_deflate), PHP ist nur der Auslöser.

Was memory_limit betrifft muss man wissen, das jeder Prozess diese 128 MB voll für sich reserviert auch wenn er nur z.B: 8 mb benötigt.

Damit ist klar das der vorhandene RAM ratz fatz futsch ist wenn eine gro0e Anzahl von Besuchern aktiv sind.

Deswegen bewirkt eine Reduzierung wahre Wunder bei hohem Andrang.

Ich empfehle normalen Usern von PCMS die das einstellen können auf 8 MB zu reduzieren, wenn nicht andere Anwendungen dagegen sprechen und es wirkt.

Ich klink´ mich mal aus, muss ein wenig arbeiten :wink:. Danke für die interessanten Beiträge, Tests und Tipps in diesem Forum.

seitenreport schrieb:

Vielleicht kann aber das PowerCMS von piratos gerade hier eingreifen und im weiteren Entwicklungsstadium genau diesen wichtigen Mittelwert finden zwischen Sicherheit & Leistungsfähigkeit auf der einen Seite und Schnelligkeit auf der anderen Seite. Interessant wäre es z.B. wenn man im PowerCMS auch TYPO3- u.o. Joomla-Extensions verwenden könnte (da hier ein sehr breites Spektrum zur Verfügung steht).

Zum einen ist es so das ich bereits in der Entwicklungsphase mit einem für viel Geld gekauften Profiscanner das Produkt beschiesse - das Produkt aber hat bislanmg da nicht eindringen können obwohl es zuzusagen mit allen Wassern gewaschen ist.
Das zum Thema Sicherheit - mehr kann ich nicht machen.

Der Scanner findet aber bei der aktuellen Typo3- und Joomlaversion diverse Möglichkeiten zum eindringen und das halte ich mal dagegen.

Zum anderen ist es so das PCMS eine andere Strategie in der Konzeption verfolgt. Ich nenne es Trennung von Frontend und Backend. Bei den noch genannten Titeln wird eine API verwendet die von zur Verfügung stehenden Einheiten (Modulen) so viel Zeugs lädt obwohl diese für eine kokrete Seite überhaupt nicht benötigt werden.
Das sich daraus ergebene Problem ist ein hoher RAM Bedarf und ein hoher Zeitbedarf und das obwohl im kritischen Fall keinerlei Aktiion daraus in der konkreten Seite erfolgt.

Und noch ein wesentlicher Punkt, ich schiebe alles wo ich es nur kann auf die Mysql - Maschine.
Manche Entwickler schieben die Langsamkeit ihres Produktes gerne auf die Mysql , die bewiesene Wahrheit ist aber, das zu viele Abfragen wegen viel zu simpler SQL erfolgen und genau das Gegenteil richtig ist, je mehr Mysql das machen kann desto besser, sparsamer und schneller wird es.

In der anstehenden Version 2 wird PCMS nochmals schneller (ca. eine Potenz), noch sparsamer, noch einfacher in der Bedienung und verfügt dann auch über einen Workflow-Mechanismus. Grund für den Leistungsschub ist die eigene Templateengine TPLE, die bereits beim Framework PowerSite seit längerer Zeit im Einsatz ist.

piratos schrieb:

Die Komprimierung wird immer vom Apache vorgenommen (z.B. mod_deflate), PHP ist nur der Auslöser.

Da kann man PHP komplett rauslassen. Ausgelöst wird es vom Browser, der sagt "Ich kann gzip". mod_deflate arbeitet ja auch mit statischen Inhalten, und immer nachdem alles andere (wie PHP oder SSI) schon gelaufen ist.
Es funktioniert ja auch komplett ohne PHP. Wenn man dagegen ob_gzhandler nutzt, umgeht man die apache Mechanismen, und muss sich mit der PHP-implementierung zufrieden geben.