gelöschter Benutzer

CSS Bewertung (Seite 8)


seitenreport
Avatar seitenreport
Inhaber
TYPO3 Senior Developer
Content Gott (1772 Beiträge)
am 17.05.2009, 14:06 Uhr schrieb seitenreport

Nachtrag für alle die TYPO3 verwenden:

(in Bezug auf Seitenreport hat eine "Zugriffs- und Generierungszeit" von 0.2 - 0.3. Sekunden)

Um TYPO3-Seiten gecached als HTML-Seiten abzulegen, installiert ihr euch die Extension nc_staticfilecache.

Dies bringt enorme Geschwindigkeitsvorteile und wird von mir daher in jedem von mir erstelltem oder von mir optimiertem TYPO3-Portal angewandt.

Die Aufrufs-Zeit einer Seite verringert sich hier durch entsprechende Anweisungen in der htaccess-Datei (siehe Extension-Dokumentation) um die einer ganz normalen HTML-Datei.

Schwierig wird es für den Statische-Seiten-Cache dagegen, wenn ihr dynamische Inhalte verwendet, z.B. Loginformular, neueste Forenbeiträge, "Sie sind eingeloggt / Forum-Rank" u.ä..

Denn dynamische Inhalte können nicht als statische Datei abgelegt werden. Dies trifft ebenfalls zu, wenn ihr in eurem TypoScript COA_INT, USER_INT oder PHP_SCRIPT_EXT verwendet.

Informationen über diejenigen Seiten von euch, die hier nicht gecached werden können, findet ihr nach der entsprechenden Extension-Installation im TYPO3-Backend unter

Info => [root-Seite auswählen] => "Statischer HTML Cache" (in der Dropdown-Liste auswählen).

Wenn nun in der Spalte "Explanation" der Wert "page has EXTincScript" für eine Seite angegeben wird, so ist diese nicht statisch cachebar, weil dynamische Inhalte enthalten sind.

Seitenreport ist es durch seine überall vorhandenen dynamischen Inhalte nicht möglich, den Statischen Seiten Cache zu verwenden. Dies macht natürlich nicht viel, da Seitenreport durch eine optimale Server- und TYPO3-Konfiguration dennoch sehr schnell ist.

Trotzdem kann die Geschwindigkeit von derzeit 0.2 - 0.3 Sekunden durch eine Aufwertung der Server-Hardware (insb. mehr Arbeitsspeicher), sowie dem Betreiben als Stand-Alone-Server noch erheblich gesteigert werden (momentan läuft Seitenreport zusammen mit allen anderen meiner Webprojekte auf einem Server).

Diese Aufwertung wird in absehbarer Zeit ohnehin nötig sein, um kommende ressourcenintensive Analysen trotz der rasand steigenden Besucherzahlen nach wie vor in dieser jetzigen Geschwindigkeit anbieten zu können.

Derzeit lohnt sich hier die Investition aber noch nicht, da der Seitenreport problemlos mit dem zehnfachen der jetzigen Besucher und Analysen fertig wird.

Daher werde ich diese Aufwertung auf den Zeitpunkt verschiebe, da Seitenreport sein fünftausendstes Mitglied bekommt :wink:

(Bei jetzigem Verlauf ca. Ende des Jahres, jedoch kann so etwas sehr schnell gehen, wenn einmal erst die "kritische Masse" überschritten ist).

Anbei findet ihr zum Herunterladen das PDF "Optimizing-TYPO3-performance", welches insbesondere auf eine optimale Server/PHP/MySQL-Konfiguration eingeht. :wink:


SEO Analyse und Website-Check mit Seitenreport


gelöschter Benutzer
am 17.05.2009, 15:07 Uhr schrieb

Der Unterschied zwischen einer gecachten Seite und einer ungecachten Seite kann erheblich sein, was die Zeit betrifft.

Nehmen wir mal meine Site mit Testergebnis hier:

0.057 sec. gecacht
0.097 sec. ungecacht

Der Nachteil liegt immer darin wenn dynamissche Komponenten enthalten sind, die man nicht cache sollte (weil die sich sonst nicht verändern).
Ãœber den Einsatz von Ajax kann man da auch mit einer gecachten Seite dynamisch arbeiten.
Eine gute CMS sollte allerdings ungecacht 0,1 ..0,15 Sekunden schaffen.


seitenreport
Avatar seitenreport
Inhaber
TYPO3 Senior Developer
Content Gott (1772 Beiträge)
am 17.05.2009, 15:26 Uhr schrieb seitenreport

Richtig, wobei heutzutage nahezu jedes größere CMS Cache-Mechanismen verwendet.

Um derartige Werte verschiedener CMS-Systeme miteinander vergleichen zu können, muss man natürlich immer auch die jeweiligen Server-Konfigurationen mit einbeziehen. Nur wenn zwei Systeme auf dem selben System verglichen werden, ist der Vergleich aussagekräftig. Wobei hier auch wieder jedes CMS verschiedene Server-Optimierungen benötigt. Zusätzlich sollte natürlich jeweils nur der selbe Funktionsumfang miteinander verglichen werden (also kein CMS, das nur einen News-Bereich hat mit einem, in dem ein Forum eingebaut ist usf.). Vielleicht hat jemand von euch gerade eine offizielle Geschwindigkeits-Liste der verschiedenen CMS im Vergleich zur Hand?

TYPO3 schafft Werte weit unter 0,1 Sekunden übrigens mit Leichtigkeit. siehe z.B. die im vorigen Jahr von mir erstellte TYPO3-Webseite der INTECO(R) GmbH.

Auf Seitenreport ist Geschwindigkeitsbremse derzeit hauptsächlich das Forum (Extension mm_forum, etwas von mir modifiziert), von dem Teile auf nahezu jeder Seitenreport-Page auftauchen. Sowie ein Server, auf dem gleichzeitig mehrere meiner ressourcenintensiven Portale (weil viele Besucher etc.) laufen. Änderungen/Optimierungen machen hier derzeit jedoch noch keinen Sinn und haben daher keine Priorität :wink:


SEO Analyse und Website-Check mit Seitenreport

seitenreport
Avatar seitenreport
Inhaber
TYPO3 Senior Developer
Content Gott (1772 Beiträge)
am 17.05.2009, 18:32 Uhr schrieb seitenreport

Analyse "Zugriffszeit / Generierungszeit" gerade etwas modifiziert, damit die Werte fairer und genauer sind:

Geschwindigkeit wird nun 3x geprüft und

$ergebnis = ($erg1 + $erg2 + $erg3) / 3;

so fließt nun auch die Geschwindigkeit der "Erstverbindung" mit in die Analyse ein.

Werte nun:

powercms.org => etwa 0.09 - 0.10 sec.
matthias-glaessner.de (GZIP komprimiert) => 0.09 - 0.10 sec.
usualredant.de (GZIP-komprimiert) => 0.10 - 0.15 sec.
seitenreport => etwa 0.70 sec.


SEO Analyse und Website-Check mit Seitenreport


gelöschter Benutzer
am 18.05.2009, 13:38 Uhr schrieb

seitenreport schrieb:

Vielleicht hat jemand von euch gerade eine offizielle Geschwindigkeits-Liste der verschiedenen CMS im Vergleich zur Hand?


Mir ist keine solche Liste bekannt.
Natürlich habe ich aber selbst die Leistungen diverser Titel verglichen.

Lokaler exklusiver Webserver, jeder Titel eine eigene DB, vergleichbarer Funktionsumfang auf der Startseite.

Bei einige Titeln sind bereits korrekte Codeteile eingefügt um Start und Endzeit wie auch RAM Verbrauch zu ermitteln.

Einige wenige Titel "bescheissen" die Anwender mit geschönten Werten, d.h. startzeit wird abgenommen an Stellen wo schon einige erhebliche Teile geladen waren und dem RAM Verbrauch wird ein "Grundbedarf" abgezogen.

Einige Titel haben dafür nichts das muss man selbst einfügen.

Cache wird grundsätzlich abgeschaltet, ebenso gzip - Komprimierung.

Generell kann man sagen, das sämtliche Titel, die Einheiten (Module etc.) generell komplett oder teilweise laden, auch wenn die für die Darstellung der konkreten Seite nicht benötigt werden nie mit den Titeln mithalten können, die tatsächlich nur das laden was benötigt wird.

Leider kann man sagen, das die Titel die wesentliche Teile von Einheiten laden die überhaupt nicht benötigt werden die Mehrzahl darstellt. Der Grund ist die meist nicht optimale Programmierung der API.

Es folgen bei immer mehrere Testläufe um einen Schnitt zu bekommen.

Und es erfolgen Läufe mit verschiedenen Fehlereinstellungen des Webservers bis hin zu E_STRICT.

Der Grund ist der das im Normalfall ein Apache auch ein Fehlerprotokoll anlegt. Ist ein Titel nicht sauber, dann wächst das Protokoll enorm und alles wird spürbar langsamer.

Zur Zeit gibt es übrigens kaum Titel die unter E_STRICT überhaupt laufen (mein Projekt natürlich ausgenommen), ja viele lassen sich darunter noch nicht einmal installieren.

Wer sich mal erschrecken lassen will der installiere mal lokal so einige bekannte Titel und check sie mal durch.

Ich könnte hier zwar ein paar Zahlen zeigen halte es aber für besser, wenn man sich selbst überzeugt.



gelöschter Benutzer
am 18.05.2009, 13:46 Uhr schrieb

seitenreport schrieb:

Werte nun:

powercms.org => etwa 0.09 - 0.10 sec.
matthias-glaessner.de (GZIP komprimiert) => 0.09 - 0.10 sec.
usualredant.de (GZIP-komprimiert) => 0.10 - 0.15 sec.
seitenreport => etwa 0.70 sec.



eben getestet:

Echte Generierungszeit:0.0006718635559082
Hier gemessen 0.065 sec.



gelöschter Benutzer
am 18.05.2009, 14:29 Uhr schrieb

Also wenn ich mit diesem Test arbeite:

<?php

function speedtest($domain=\'powercms.org\')
{ $starttime = microtime(true);
$ch = curl_init(\'http://\'.trim($domain));
curl_setopt($ch, CURLOPT_TIMEOUT, 50);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1");
$curl_ret = curl_exec($ch);
curl_close($ch);
$gesamt =microtime(true) - $starttime;
$s=strlen($curl_ret) /$gesamt;
echo \'

# \'.$domain.\' Gesamtzeit:\'. $gesamt.\' Bytes pro Sek. \'.round($s).\'

\';
}


speedtest();
speedtest();
speedtest();
speedtest(\'www.seitenreport.de\');
speedtest(\'www.seitenreport.de\');
speedtest(\'www.seitenreport.de\');

?>

Dann erhalte ich von mir aus (20 Mbit) folgende Resultate:

# powercms.org Gesamtzeit:0.11987614631653 Bytes pro Sek. 200515

# powercms.org Gesamtzeit:0.12364196777344 Bytes pro Sek. 194408

# powercms.org Gesamtzeit:0.12732911109924 Bytes pro Sek. 188779

# www.seitenreport.de Gesamtzeit:0.65734100341797 Bytes pro Sek. 45879

# www.seitenreport.de Gesamtzeit:0.66808700561523 Bytes pro Sek. 45141

# www.seitenreport.de Gesamtzeit:0.67128205299377 Bytes pro Sek. 44926

und das wäre die echten Zeiten die ich warten muss bis der reine HTML Inhalt bei mir eingetrudelt ist.

Ich glaube man sollte diese Methode wählen 1 x durchlaufen lassen und die Bytes pro Sekunde als Massstab nehmen.

Damit wären alle belohnt die a. eine schnelle cms haben, b. einen schnellern Webserver haben und c. die gzip verwenden.

Da man die Analyse immer von deinem Webserver aus startet spielt zum Vergleich auch ping keine bedeutetende Rolle.



gelöschter Benutzer
am 18.05.2009, 14:32 Uhr schrieb

Nehme ich mal unseren Tabelleersten (z.Z) dann hat der folgendes:

# www.pragmamx.org Gesamtzeit:0.16086411476135 Bytes pro Sek. 100060

# www.pragmamx.org Gesamtzeit:0.19241094589233 Bytes pro Sek. 83654

# www.pragmamx.org Gesamtzeit:0.15543580055237 Bytes pro Sek. 103554



gelöschter Benutzer
am 18.05.2009, 14:35 Uhr schrieb

Und hier mal einen der nur eine Einstiegsseite also wenig Inhalt anbietet:

# www.sittardsberg.de Gesamtzeit:0.04784893989563 Bytes pro Sek. 63282

# www.sittardsberg.de Gesamtzeit:0.056719064712524 Bytes pro Sek. 53386

# www.sittardsberg.de Gesamtzeit:0.050332069396973 Bytes pro Sek. 60160

Man kann nun klar erkennen, das bei einer Bemessung Bytes Pro Sekunde ein wesentlich deutlicheres Bild heraus kommt.



gelöschter Benutzer
am 18.05.2009, 16:21 Uhr schrieb

Noch die Zusatzinformation zu o.a. Script bzw.Test.

Ping bei seitenreport.de 16 ms

Ping bei 19.4 ms

Was beweist das die aktuellen Ergebnisse hier uas dem Test nicht stimmig sind.




« zurück zu: Feedback

Das Seitenreport Forum hat aktuell 5275 Themen und 36110 Beiträge.
Insgesamt sind 48360 Mitglieder registriert.