Verzicht auf Typo3 wegen Performance-Risiko?

Wenn jeder davon durchschnittlich 3 Minuten verweilt, kommt in eine Parallelität von 10 Usern zustande. Kann man das mit 10 Zugriffen pro Sekunde gleichsetzen?

Nicht wirklich 😉 Wenn diese 10 User jede Sekunde eine neue Seite anklicken, dann schon. Wichtig wäre noch zu wissen, wielange die User auf jeweils einer Seite bleiben. Aber ich schätze, das es mindestens 3 Sekunden pro Seite sind (ich glaube eher länger...).

Was sind "relativ statische Seiten"? Sind Seiten, die aus dem typo3-Cache geladen werden, genau so schnell wie statische (html-)Seiten?

Typo3 generiert "normale Seiten" ohne irgendwelche berechnenden Extensions EINMAL. Dann gibt es diese fertige Seite im Speicher und kann direkt geladen werden. Mir ist nicht bekannt, das eine Seite aus dem Typo-Cache langsamer lädt als eine "normale" HTML-Seite.

Es gibt hier einige Threads zum Thema: Wie mache ich Typo3 schneller. Wichtige Faktoren: valider Html-Code, alles auslagern, was nur geht (Stylesheet),...

Heißt das, dass bei hohem Aufkommen die Hardware erweitert wird und damit Performance-Einschränkungen stark frequentierter dynamischer Seiten ausgebügelt werden können. Ist diese Methode preislich verträglich?

Naja, preislich verträglich ist relativ 😉 Aber bei den genannten Zahlen, wird man auf so ein System wohl verzichten können.

Mein Tipp: Einfach mal kompetente Typo3-Hoster fragen, was die von der Sache halten.
Zwei würden mir spontan einfallen:
http://www.typo3server.com/
http://www.jweiland.net

Gruss

Michael

Vielen Dank für die Aufhellungen. 🙂

Im Forumbereich "Grundsätzliche Frage" gibt es den Topic "Performance von Typo3 - Grenzen". Im 5. Beitrag stellte Rene_Ott eine interessante Grundsatzfrage:
"Woher kommt der Hardwareverbrauch von Typo, werden z.B. übermässig viel SQL-Statements abgesetzt?"
Als Antwort kam von TnT, dass dies "besonders" für die Erstellung der Seite gelten würde, während zu "Lifetime" (ich nehme mal an, damit meint er den Userzugriff) auf den Cache verweist.

Rene_Ott schob nach (ohne Responseergebnis):
"[​i]...Und da würde es mich interessieren, ob andere CMS da einen ähnlichen Rerssourcenverbrauch haben wie Typo3 oder der Verbrauch deutlich niedriger bzw. höher liegt.
Wer also schonmal Erfahrungen in dieser Hinsicht gesammelt hat, möge diese doch mal unverschämt posten [/i]". Er blieb ohne Response!

Mich wundert, dass Performance hier so spärlich diskutiert wird. Ich vermute, dass aufgrund der hohen Vorkonfigurierung und den ausgeprägten Möglichkeiten für die anwenderfreundliche Pflege und Gestaltung Typo3 bezüglich Performance vergleichweise schlecht da steht.

Die Wirkung der "ausgleichenden" Faktoren Cache und Hardwareaufrüstung erscheinen mir in den wenigen Topics, die sich damit beschäftigen, verschwommen argumentiert.

Zum Cache würde mich interessieren, ob er alle Seiten des Webauftritts enthalten kann und ob er diesbezüglich vorgefüllt werden kann?

TnT schrieb

Aber bei den genannten Zahlen, wird man auf so ein System wohl verzichten können.

Ich bin hinsichtlich Performance sehr sensibel. Ich habe zwar noch nicht beim Surfen Zehntelsekunden gestoppt, aber ich behaupte Seitenaufrufzeiten von 3 Sekunden können jemanden, der wenig Zeit hat und lediglich reine Informationen sucht, bereits nerven.
Bin ich da zu pingelig?

sabineg schrieb

Ich habe zwar noch nicht beim Surfen Zehntelsekunden gestoppt, aber ich behaupte Seitenaufrufzeiten von 3 Sekunden können jemanden, der wenig Zeit hat und lediglich reine Informationen sucht, bereits nerven.
Bin ich da zu pingelig?

Ja, bzw. denkst Du über das potentiell falsche Ende nach.

Wenn Du einen Seitenaufbau von unter 3 Sek. konstant erreichen willst, unabhängig davon mit was der User angeschlossen ist (33,6er Modem?) etc. dann solltest Du Dir VIEL mehr Gedanken um die Datengröße der einzelnen Seite machen, als um Responsezeiten des Servers! Wenn Du die Zeit für den Abruf einer Seite aus dem DB Cache mit der Zeit zur Übertragung und Darstellung vergleichst, wirst Du feststellen, dass erstere ein Bruchteil ist. Auf jeden Fall freue ich mich schon Deine Grafik freie Textwebsite zu sehen. 🙂

mstuebner schrieb

Wenn Du einen Seitenaufbau von unter 3 Sek. konstant erreichen willst, ...dann solltest Du Dir VIEL mehr Gedanken um die Datengröße der einzelnen Seite machen, als um Responsezeiten des Servers! Wenn Du die Zeit für den Abruf einer Seite aus dem DB Cache mit der Zeit zur Übertragung und Darstellung vergleichst, wirst Du feststellen, dass erstere ein Bruchteil ist. Auf jeden Fall freue ich mich schon Deine Grafik freie Textwebsite zu sehen. 🙂

:o :o 🙂 Hm ...., ja, klingt überzeugend.

Kann ich eigentlich den Cache mit allen Seiten (komplette Inhalte der Seite) vorfüllen oder gibt es da Kapazitäts- oder sonstige Restriktionen?

Kann man ohne Brimborium testen (oder gar abschätzen), welchen Einfluss die Datenbefrachtung einer Seite auf die Zugriffszeit hat?

sabineg schrieb

Kann ich eigentlich den Cache mit allen Seiten (komplette Inhalte der Seite) vorfüllen oder gibt es da Kapazitäts- oder sonstige Restriktionen?

Über Restriltionen der DB informiert Dich bestens: mysql.com

sabineg schrieb

Kann man ohne Brimborium testen (oder gar abschätzen), welchen Einfluss die Datenbefrachtung einer Seite auf die Zugriffszeit hat?

Irgendwie verstehe ich Dich schon rein sprachlich nicht. Was ist eine "Datenbefrachtung"?

BTW: Was stellst Du Dir eigentlich als Ergebniss Deiner Recherchen vor? Ein Garantiezertifikat darüber, dass T3 mit der gewaltigen Anzahl von 200 Besuchern pro Tag klarkommt? 😃 Das kasst Du wohl durch den Einsatz potenter Hardware sehr genau steuern...

mstuebner schrieb

sabineg schrieb

Kann ich eigentlich den Cache mit allen Seiten (komplette Inhalte der Seite) vorfüllen oder gibt es da Kapazitäts- oder sonstige Restriktionen?

Über Restriltionen der DB informiert Dich bestens: mysql.com

Bei mysql.com habe ich nichts darüber gefunden, wie weitgehend der cache gefüllt werden kann.
Beim Googeln fand ich das:
"Um die Aufrufzeit unserer Internetseiten zu verkürzen, werden ab sofort (20.7.04) einmal täglich alle Seiten des Internetauftritts als statische Seiten gespeichert. Alle Aufrufe in der Form http://www.fh-coburg.de/xyz oder http://www.fh-coburg.de/xyz.html liefern ab sofort nur noch statische Seite vom Webserver. Ausgenommen sind alle Seiten auf denen erfahrungsgemäß sich fast ständig etwas ändert. Bei diesen Seiten sollte man bereits beim Erstellen das Feld "Cache verfällt" auf "1 Stunde" stellen."
Das klingt so, als ob alle Seiten im cache untergebracht werden konnten. Die Internetseite ist in der Tat sehr schnell, was man von anderen Typo3-Seiten nicht behaupten kann.
Wenn es trotzdem relevante Restriktionen bezüglich des Zusammenhangs mysql und dem Typo3-cache gibt, habe ich dafür ein offenes Ohr. 😉

Irgendwie verstehe ich Dich schon rein sprachlich nicht. Was ist eine "Datenbefrachtung"?

Mit Datenbefrachtung meine ich wieviel KB Daten auf der Seite sind. Wenn beispielsweise viele Bilder dargestellt werden müssen, dann steigt die Datenmenge der Seite.

BTW: Was stellst Du Dir eigentlich als Ergebniss Deiner Recherchen vor? Ein Garantiezertifikat darüber, dass T3 mit der gewaltigen Anzahl von 200 Besuchern pro Tag klarkommt? 😃 Das kasst Du wohl durch den Einsatz potenter Hardware sehr genau steuern...

Wieviel pro Tag kommen ist ziemlich egal. Ich schätze mal 400. Wichtig und aufgrund der Art unseres Angebotes besonders relevant sind die Zugriffsspitzen und da sollte das System in der Lage sein mehrere gleichzeitige Zugriffe locker zu verkraften.

Ich habe aber nun verstanden, denke ich mal, dass man mit dem Cache und geeigneter Hardware Typo3 für meine momentanen Zwecke nutzen kann. Vielen Dank für die Infos. 🙂

Zu beachten für eine mögliche Perfomance ist auch die Grundsätzliche Programierung der Seiten in Typo.
Wird z.B: extrem viel Gif-Builder-Funktionalität oder z.B: X-Menu-Layer mit exp_all verwendet kann das schon ein bisserl länger dauern wie eine gut optimierte Seite. Das gehört aber alles gundsätzlich in die Konzeptphase für das Projekt. Wo man auch die Anbindung des Servers mit beurteilen sollte.

Eine weitere Möglichkeit die Performance zu steigern wäre die Möglichkeit eines Reverse-Proxys. Das kann man aber meinst nur in Unternehmens-Netzen einsetzen.

Zu guter Letzt sollte man eventuell auch noch die Outraxx-Extension in Betracht ziehen mit der man wirkliche Statische-Seiten generieren kann.

Grüße

Danke Bps!

Ich habe das schlaue Buch "Content Management mit Typo3" von Andreas Stöckl. Er weist auf den Caching-Mechanismus hin, was bedeutet, dass nur aus einer Datenbanktabelle gelesen wird.
Er räumt allerdings ein, dass der Einsatz von Staging Servern nicht möglich sei und damit "Typo3 für Websites mit hoher Last nicht geeignet" sei. Wo hohe Last anfängt, darüber schweigt er sich aus.

Natürlich kann man auch fragen, ab welcher Zeitgrenze ein Seitenaufbau nicht mehr akzeptabel sei. Weil ich gerade bei meinen Kunden von sehr knappen Zeit- und Lustressourcen beim Internetbesuch ausgehe, möchte ich, dass sich die Seiten meiner Homepage extrem schnell aufbauen.

Warum ist der Typo3-Cache eigentlich per se nie so wirkungsvoll wie eine html-Seite? Weil der Cache immerhin noch den Zugriff auf eine DB-Tabelle leisten muss, während html ohne DB-Zugriff auskommt?

Kann bei den Gif-Builder-Funktionalitäten nicht der Cache-Mechanismus greifen?

Heisst "X-Menu-Layer mit exp_all", dass mit jedem Seitenaufruf die Navigationsleiste neu aufgebaut wird?

Die Outraxx-Extension habe ich bei Outraxx.de gefunden. Es geht wohl um das Modul "Static Publish". Können damit alle Seiten statisch vorgehalten werden und wird damit der gleiche Performanceeffekt wie bei einem Staging-Mechanismus erzielt?

Wozu dient eigentlich das Verzeichnis "publish" in Typo3? (Fand ich da: #30581)

sabineg schrieb

Er räumt allerdings ein, dass der Einsatz von Staging Servern nicht möglich sei und damit "Typo3 für Websites mit hoher Last nicht geeignet" sei. Wo hohe Last anfängt, darüber schweigt er sich aus.

Das ist auch nicht ganz so einfach abzuklären. Prinzipiell gibt es Websites, z.B. HP.com oder andere Websites mit recht hohem Traffic wo man im moment den Einsatz von Typo3 abraten sollte. Weil es einfach dein Mechanismuss des LPE (Live-Production-Enviroment) wie es andere Systeme bieten noch nicht direkt hat.

Also wo die hohe Last anfängt und wo nicht hängt einfach auch von mehreren Faktoren ab. Welcher Server? Ist Datenbank und HTTP-Server auf der selben Maschine oder getrennt? usw.. Allein die Konfiguration des Servers kann schon erheblichen Einfluss auf die Performance haben.

sabineg schrieb

Natürlich kann man auch fragen, ab welcher Zeitgrenze ein Seitenaufbau nicht mehr akzeptabel sei. Weil ich gerade bei meinen Kunden von sehr knappen Zeit- und Lustressourcen beim Internetbesuch ausgehe, möchte ich, dass sich die Seiten meiner Homepage extrem schnell aufbauen.

Hier spielt wie gesagt nicht nur Server und System eine Rolle. Das fängt natürlich auch bei Konzept und Design an. Ist eine Website performance ungünstig gestaltet kann dadurch das ganze System ausgebremst werden.

sabineg schrieb

Warum ist der Typo3-Cache eigentlich per se nie so wirkungsvoll wie eine html-Seite? Weil der Cache immerhin noch den Zugriff auf eine DB-Tabelle leisten muss, während html ohne DB-Zugriff auskommt?

Das ist auch mit einer der Gründe. Bei einer statischen HTML-Seite sendet der Webserver enfach nur die Seite an den User.. das geht entsprechend schnell. Bei einer PHP-Seite wird die Seite ersteinmal duch den Interpreter geleitet und dazu kommt natürlich noch der Datenbankzugriff das ist einfach langsamer als eine statische Seite.
Allerdings ist Typo durch die Cache-Funktionalität da gar nicht schlecht..

sabineg schrieb

Kann bei den Gif-Builder-Funktionalitäten nicht der Cache-Mechanismus greifen?

Greift dort auch, aber aus Erfahrung sind z.B. per Gifbuilder berechnete Menus wesentlich langsamer als als normale Textmenus.

😃

Hallo,

Ich habe diesem Thread mal beobachtet und stelle mal meine Erfahrungen zum Thema Last auf einem Webserver dar.

Wir betreiben unter anderem einen Teil des Intranet der Deutschen Post. Pro Tag haben wir während der Kernarbeitszeit (also etwa 9 Stunden) 40000 (40 tausend) Zugriffe auf eine dynamisch generierte Webseite. Zugegeben: nicht auf Typo3 Basis.

Etwa 25000 davon sind SSL verschlüsselt, was extrem hohe Last auf den Servern verursacht.

Eine dicke Sun Enterprise 6500 mit 8 Prozessoren und 16GB RAM ist mit etwa 60 SSL Verbindungen ausgelastet, wobei nicht-SSL Verbindungen gleichzeitig etwa 2000 abgearbeitet werden können.

Wir haben dazu ein Load-gebalanctes System mit 6 Servern aufgebaut.

Wenn Du also eine Webseite mit einer durchschnittlichen Seitengröße von 25 Kilobytes (HTML + CSS + Grafiken)und einer Ladezeit (per DSL) von etwa 1 Sekunde ausgehst, wird ein normaler Pentium 4 basierter Server nicht in die Knie gezwungen.

Der Server sollte viel RAM haben (mind. 1GB), da die Leistung von Datenbanken (z.B. mySQL) sehr stark vom RAM abhängt. Die Zugriffsgeschwindigkeiten von Datenbankservern liegt in etwa im Bereich von Filesystemzugriffen, da Datenbanken mehr RAM-basierten Cache nutzen können, den ein Betriebssystem für das Filesystem nicht zur Verfügung hat.

Sprich, sofern sich der dynamische Content nur sagen wir einmal täglich ändert (durch z.B. Aktualisierung der Tageskarte), dann wird nur der Erste Zugriff auf den neuen Content neu berechnet, was vielleicht 2 Sekunden dauert. Alle anderen greifen auf den (recht schnellen) DB Cache zu.

Der DB-Cache für Typo3 ist dabei nichts anderes als eine normale Tabelle in der Datenbank. Der DB interne Cache ist nochmal was anderes.

Typo3 holt sich die Inhalte der einzelnen Tabellen, baut die Zeichenkette auf die letztlich das HTML der Webseite darstellt und speichert diesen String in eine Tabelle der Datenbank, die unter dem Begriff Typo3-Cache bekannt ist. Beim nächsten Zugriff auf diese Seite holt Typo3 nur diese Zeichenkette ab und spart sich also die Seite neu zusammenzubauen.

Ich hoffe etwas Licht ins Dunkel gebracht zu haben. Die Quintessenz des Ganzen ist, daß ein eigener, halbwegs moderner Server (also Root- oder Managed Server, 2,5GHz, 1GB RAM) eine Webseite unter Typo3 für 200 einigermaßen gleichzeitiger Sessions durchaus locker bewältigt.

Gruß, l.