Kann Typolight hohe Besucherzahlen verkraften und läuft dann noch stabil?

Hallo! Da ich mich auf Typolight bzgl. bisheriger Arbeiten eingeschworen habe, möchte ich auch gerne das CMS zum Einsatz kommen lassen, was die Website für eine in Zukunft liegende Karate-Weltmeisterschaft angeht. Die Austragenden haben bereits eine EM erfolgreich bestritten und monatlich waren Besucherzahlen von 1,2 Mio. wohl keine Seltenheit. Kann nach Eurer Einschätzung TL dem standhalten?
Und vielleicht abgesehen von dem einfachen gleichzeitigen Surfen auf den Seiten.
Wie steht es zum Beispiel mit dem Zugriff auf Downloaddaten oder das gleichzeitige Abrufen von Videos?
Danke für Eure Meinungen!

ich selber hab zwar keine Mio Besucher, aber aus meiner Sicht muss das in 1. Linie der Server regeln. TYPOlight an Sich ist nicht Ligth :D. Wenn die Seiten anständig gecacht werden denke ich das TL das genau so regeln kann wie zB TYPO3 bzw Drupal.

Irgendwo im Forum gibt ein Thread mit den größten und aufwändigsten TL Projekten da sind auch richtig große Seiten dabei.

Wie gesagt das ist meine Einschätzung ich kanns nicht beweisen :)

Schau mal hier --> https://contao.org/neuigkeiten/items...-geeignet.html. Mehr als 15.000 Besucher am Tag ist schon ordentlich :cool:

Hallo koopoo,

vielleicht hilft diese Ankündigung…
(trotz 2 Espressi zu langsam Alex ;) )

Ich glaube es ist unredlich, ohne Infos über die zugrunde liegende Hardware Aussagen zu machen. Egal wie "light" ein System ist, wenn der Server nur schwach genug ist (Shared Hosting Marke "Billig"), wird es irgendwann kollabieren. Und umgekehrt, wenn meine Seiten am Ende sind, dann muss ich "nur" genügend Hardware (DB-Server, Static-Content-Server mit lightweight-Webserver, Loadbalancing, memcache) draufschmeissen, ums am Laufen zu halten.

Leider steht im oben genannten Link keine Info, wie die zugrunde liegende Serverstruktur aussah. Ich kann mir nicht vorstellen, dass das auf nur einem einzigen Webserver lief. Andererseits weiss ich nicht, ob TYPOlight (leicht) in der Lage ist, auf mehreren Webservern (Loadbalancing) zu laufen. Thema Session Data...

In einer der letzten Folgen des Technikwürze-Podcasts hat jemand umfangreich über seine Maßnahmen zur Performance-Steigerung durch mehr Hardware berichtet (Aber nicht spezifisch für Typolight).

Stefan

Ich würde sagen: "Fragen hilft" ! Einfach mal bei dem Ersteller der Webseite http://www.webseason.com/ nachfragen. ich denke die werden da gerne Auskunft geben.

Zitat:

---

Zitat von alex

Ich würde sagen: "Fragen hilft" ! Einfach mal bei dem Ersteller der Webseite http://www.webseason.com/ nachfragen. ich denke die werden da gerne Auskunft geben.

---

WebSeason gibt's leider nicht mehr...

Wichtig ist aus meiner Sicht wie du TYPOlight konfigurierst, dann klappt das schon. 1. solltest du unbedingt das Caching aktivieren, zweitens ggf. Dateien auf ein CDN auslagern.

Zitat:

---

Zitat von leo.unglaub

bei 15 000 Besuchern pro tag? Locker, da langweilt der sich aber mächtig nebenbei. Unterschätze niemals die Rechenpower von moderner Hardware.

---

Mit Videostreaming usw?

Naja, dann muss sich die Karateweltmeisterschaft ja keine Sorgen machen. Die rechnen ja nur ca. mit dem dreifachen. Wird dann wohl gut klappen, solange der Hobel stark genug ist. Auf nem Single-Core mit 1GB RAM würde ich es nicht machen.

Stefan

Hiho!

Genau weiß ich es auch nicht, aber ich hab mal aus Neugier ab verschiedene meiner Seiten losgelassen. TYPOlight hat erstaunlich gut unter Last reagiert! :-)

Aber ich hab nur shared hosting, bei so einem Projekt hast Du ja ganz andere Möglichkeiten:

- Revers Proxy vor dem Webserver
- Streaming von Videos hat garnix mit TL zu tun, eventuell auf einen eigenen Server auslagern
- Downloads auch auf einen eigenen Server, zusammen mit allen anderen statischen Inhalten
- ...

Bei so einem Projekt braucht es aber Fachwissen, das man sicher auch einkaufen kann und eventuell sollte!

Tschüss
Marcus (aka Tiggr)

... dann kann ich die unangenehme Option, mich in Typo3 einzuarbeiten – da dieses eigentlich redakteurseitig als bevorzugtes CMS geünscht war – ja getrost lassen.
Damit steht der Entscheidung für Typolight wohl nichts mehr im Weg!!!
Herzlichen Dank! :):):);)

Nur als Kommetar zum Streaming:
Ich habe, in kleinerem Maßstab allerdings, sehr gute Erfahrungen mit Amazon S3 und der Streaming Option gemacht. Das Einbinden der Videos gelingt mit den gängigen Playern leicht. Nicht getestet habe ich das Zusammenspiel der diversen Erweiterungen mit Amazon.
Insgesamt klappt sehr einfach und entlastet natürlich den Server. Andreas hat das ja schon allgemein angesprochen (CDN). Natürlich gibt es auch noch andere Angebote als das erwähnte. Der Nachteil sei nicht verschwiegen: storage, request und traffic kosten natürlich.

Ich hab hier bei der letztjährigen Rollkunstlauf-WM (ok, nicht ganz vergleichbar mit einer Judo-EM/WM) in der Technik mitgeholfen (wenn auch nicht Internet, aber hab da einiges mitbekommen). Videos wurden da komplett auf YouTube ausgelagert. Einbindung ist ja kein Problem, und man hat gleichzeitig noch ein wenig eine Werbeplattform. Auch interessant (meines Erachtens für soetwas noch besser) ist vimeo. Eigenen Kanal anlegen, Videos rein, auf der Seite einbinden, Problem erledigt. Warum das Rad neu erfinden? ;)

Zitat:

---

Zitat von FloB

(ok, nicht ganz vergleichbar mit einer Judo-EM/WM)

---

Auch nicht vergleichbar mit einer Karate-WM :p

Judo … Karate … wie auch immer, es liegt am Schluss immer Einer auf dem Boden ;).

Zitat:

---

Zitat von koopoo

... dann kann ich die unangenehme Option, mich in Typo3 einzuarbeiten – da dieses eigentlich redakteurseitig als bevorzugtes CMS geünscht war – ja getrost lassen.
Damit steht der Entscheidung für Typolight wohl nichts mehr im Weg!!!
Herzlichen Dank! :):):);)

---

Mit TYPO3 würde ich das sowieso nicht vergleichen - TYPOlight ist da immer im Vorteil.

So wie es aussieht, hat es noch nie jemand mit dieser Größenordnung versucht. Und aus eigener Erfahrung mit anderen CM-Systemen weiß ich, dass jedes davon ab einer gewissen Grenze anfängt, komisch zu reagieren. Jenseits dieser Grenze hilft dann auch beliebig viel Hardware nichts mehr. Bei statischen Seiten kann man sich natürlich mit Proxys etc. behelfen, und der CDN-Tipp ist auch sehr hilfreich, aber wenn Communities ins Spiel kommen, wird es bei vielen finster. Gut, diese Erfahrungen habe ich mit Java-Systemen gemacht, aber ich denke PHP wird da nicht besser dastehen.

Bitte nicht falsch verstehen: soweit ich es beurteilen kann, ist TYPOlight sauberer und schlanker als T3 (und alle anderen PHP-CMS, die ich kenne) und dürfte vermutlich dem Ansturm standhalten. Aber auf solche Vermutungen alleine begründet, würde ich keinesfalls ein High-End-Projekt umsetzen.

Ein großer Kunde von mir hat in seinem Rechenzentrum eine eigene Truppe, die nichts anderes macht, als neue Anwendungen umfangreichen Lasttests zu unterziehen. Dazu gibt es unterschiedliche Strategien - die richtig teuren sind quasi "bestellte" DOS-Attacken, die einfachste Methode ist eine Software, die die Zugriffe simuliert. Kostet ab 600 Euro und sollte für solche Anwendungszwecke ausreichend sein.

Bei High-End-Anwendungen musst du sowieso immer selber Hand an die Software legen. Für wahre High-End-Anwendungen bräuchte TL internes Caching des Dateibaumes (über mehrere Instanzen hinweg) sowie ein granulares FE-Caching (Caching von HTML-Snippets) und weitere Laufzeit-Optimierungen im Core.

Dadurch geht aber natürlich die Flexibilität verloren, sodass man diese Änderungen niemals gänzlich in den Core aufnehmen könnte. Es ist immer noch ein CMS und keine Software für High-End-Anwendungen.

Auf der anderen Seite hat TL schon einen Vorteil gegenüber einiger anderer Systeme: Die Konfiguration wird komplett über PHP-Variablen gesteuert, somit entfällt das Parsing von Konfigurationsdateien (z. B. auf Basis von XML). Auch für das Templating wird voll auf PHP-Code gesetzt, was nicht nur Flexibilität innerhalb der Templates ermöglicht, sondern den Generierungsaufwand im Vergleich zu Template-Engines drastisch reduziert.

Somit ist TL für Anwendungen mit hoher Last durchaus geeignet. Natürlich sollte man Hardware-seitig und auch Software-seitig ein wenig optimieren, wenn es an die Lastgrenze geht (z. B. auch APC, memcached einsetzen). Trotzdem sollte man ab einer gewissen Auslastung den Core weiter auf seine Bedürfnisse anpassen oder eine eigene Software schreiben. Aber ab diesem Punkt ist man in der Regel an so einem Projekt nicht alleine vollzeitbeschäftigt – wenn man es richtig macht.

Zitat:

---

AB und ich haben TL schon oft gefordert

---

Wusste ich nicht, glaube ich auch erstmal, aber wenn ich selbst ein solches Projekt vor der Brust hätte, würde ich da viel detaillierter nachfragen: wieviele Seiten? welche Verteilung der Zugriffe über den Tagesverlauf? Gibt es Lastspitzen im typischen Nutzungsverhalten? Wieviele Autoren? Wieviele Besucher genau? Schreiben Besucher auch (Community)? Wie sind die Besucher regional verteilt? Welcher Hobel wird genau verwendet? Wie ist er ans Internet angebunden? Muss der gleiche Server auch die Binaries ausliefern? Welches Caching wird verwendet?

Zitat:

---

Es macht bei TL iel aus ob man weiß was man macht oder ob man einfach so was damit erstellt.

---

Für einen Lasttest ist es irrelevant, ob die Testsoftware (oder das Testverfahren) das Testobjekt kennt, denn die Aufgabenstellung einer solchen Software ist: "Kommt die Anwendung in der aktuellen Konfiguration mit einer gewissen Last klar oder nicht?" Die Antwort ist "ja" oder "nein" - je besser die Software oder allgemein das Testverfahren, desto brauchbarer dürften dann noch die Tipps sein, an welchen Stellen man schrauben kann. Für die Optimierung selbst ist dann natürlich wieder die intime Kenntnis der Software gefragt, und ich glaube das ist es, was Du meinst. Aber die Kenntnis alleine reicht eben nicht, um das Verhalten des Systems unter Last genau vorhersagen zu können - das muss man einfach ausprobieren.

Ich glaube, wir reden völlig aneinander vorbei. Ich habe nie behauptet, Techniker zu sein, aber ich habe die Angewohnheit, Technikern zuzuhören. Und die, von denen ich meine Weisheiten habe, wissen sehr wohl, wovon sie sprechen, meine ich.

Nochmal: ich habe nicht gesagt, dass TL es nicht draufhat, sondern dass ich mehr wissen wollen würde als die Aussage "passt schon" von jemandem in einem Forum, den ich überhaupt nicht kenne, und den ich nicht belangen kann, wenn er sich getäuscht hat.

Nur ein Beispiel, welches Du mit einem Nicht-Argument weggewischt hast: ich kenne Systeme, die locker 100.000 Seitenzugriffe in der Stunde packen, sobald ein Redakteur im Backend eine Seite abspeichert aber schon bei 5.000 ins Keuchen kommen. Im konkreten Fall gings es soweit, dass man Redaktionsystem und Webserver trennen musste. Dieser Effekt hat laut deiner Aussage keine Relevanz - und das ist schlichtweg falsch.

Den Seitenhieb auf den Unternehmensberater hättest Du Dir übrigens verkneifen können, ganz ehrlich: das empfand ich als unhöflich und unangebracht, zumal ich nicht den Eindruck habe, dass Du meinen Post aufmerksam gelesen hast.

Dass Du dich auskennst: unbenommen. Aber muss denn automatisch jeder andere ein Depp sein?

Kommt bitte etwas runter Jungs, diese - interessante - Diskussion kann man auch gut entspannt und ohne Stress führen. Gönnt dem Forenteam doch ein paar ruhige Ostertage und diskutiert das friedlich weiter ;) :)

Hiho!

Zitat:

---

Nur ein Beispiel, welches Du mit einem Nicht-Argument weggewischt hast: ich kenne Systeme, die locker 100.000 Seitenzugriffe in der Stunde packen, sobald ein Redakteur im Backend eine Seite abspeichert aber schon bei 5.000 ins Keuchen kommen.

---

Kann ich mir gut vorstellen, beim Speichern werden die Indizes akualisiert! Speichern ist unglaublich viel teurer als lesen - bei Datenbanken!

IMHO braucht es keine teure Testsoftware, ab reicht voll!

Aber eine gute Strategie, wie man mit der Last umgeht ist wichtig! Und da wage ich zu behaupten, das mit den bisherigen Angaben zur geplanten Seite keine wirklich fundierte Aussage möglich ist!

Testen, überlegen, planen, testen, das ist der Weg!

Zitat:

---

sondern dass ich mehr wissen wollen würde als die Aussage "passt schon" von jemandem in einem Forum, den ich überhaupt nicht kenne, und den ich nicht belangen kann, wenn er sich getäuscht hat.

---

Das gefällt mir garnicht, vor allem nicht das "belangen können". Niemand kann einem die Verantwortung für die Entscheidung abnehmen. TL ist toll, aber man kann jedes System an die Grenzen treiben. Viele SQL-Queries und wenig granulares Caching könnten TL ungeeignet machen!

Testen, überlegen, planen, testen, testen!

Eventuell macht es sogar Sinn für so ein großes Projekt selbst was zu entwickeln - Twitter, Facebook und Youtube laufen ja auch nicht auf einem TL, Typo3 oder Joomla, sondern haben was eigenes Entwickelt!

Tschüss
Marcus (aka Tiggr)

Hallo Tiggr,

das mit dem "Belangen" ist nach meiner Erfahrung im Bereich großer, professioneller Projekte üblich.

Wenn ich einen Auftrag in der Größenordnung annehme, stehen im Vertrag in der Regel auch Haftungsregeln, denn wenn beim Kunden echter wirtschaftlicher Schaden entsteht, wird der sich absichern wollen.

Er wird also für Risiken, die in meinem Einflußbereich liegen, mich - zu Recht - verantwortlich machen.

Wenn ich jetzt davon keine Ahnung habe, würde ich persönlich zu Leuten mit Ahnung gehen (wie z.B. Leo) und sie - gegen Bezahlung - um eine Abschätzbarkeit des Risikos bitten. Wie die das nun genau machen (AB, teure Tools, DOS-Attacken ...) wäre mir dann egal, in jedem Fall wäre auch in diesem Vertrag eine Haftungsregelung drin.

Natürlich kann man so nicht alle Risiken abdecken, aber alle Beteiligten schlafen etwas besser und es geht - aus meiner Sicht - fair zu.

Ansonsten: testen - überlegen - planen - testen - full Ack.

Hiho!

Zitat:

---

das mit dem "Belangen" ist nach meiner Erfahrung im Bereich großer, professioneller Projekte üblich.

---

Jupp, bei großen, professionellen Projekten. Da wir ein Pflichtenheft erstellt, gemeinsam besprochen, zum Teil der Vertrags gemacht, Haftungen geklärt, alles klar...

Nur in einem Forum find ich es schon ziemlich seltsam das Thema zur Sprache zu bringen. IMHO dienen Foren der allgemeinen Informationen und gegenseitigen Hilfsbereitschaft.

Im professionellen Umfeld dienen die doch höchstens dazu einen ersten Eindruck zu bekommen.

Tschüss
Marcus (aka Tiggr)

Ganz genau, so habe ich das auch gemeint - denn ich war davon ausgegangen, dass das Projekt des OP in eine solche Dimension mit Verträgen etc. hineinragt :)

und was ist mit Kleinprojekten, die aber aller Wahrscheinlichkeit nach vielleicht ein mal im Jahr einen Riesenansturm haben?

Ich wollte gerne eine Künstlerseite mit TL bauen. Wenn dieser Künstler nun zB. von der Bild auf deren Startseite ein Feature bekommt, dann meinte der Redakteur zu mir, dass ich bei entsprechendem Bildmaterial (zB. Skandal mit 10 barbusigen Tänzerinnen) schnell mal mehrere Millionen Seitenaufrufe in einem Zeitfenster von wenigen Stunden einplanen muss, weil dann wahrscheinlich deren gesamter Besucherstrom sich das genauer anschauen will.

Ansonsten wird sich aber TL mit Sicherheit langweilen... wie kann man da am besten Vorsorgen (mal vom obligatorischen Caching abgesehen). Einen entsprechenden Hoster einplanen, der irgendwelche Hardwarevoraussetzungen (welche genau?) für ein bestimmtes Zeitfenster zur Verfügung stellt? Oder wie geht man da vor?
Problematisch ist auch das Anbieten des Videos, denn solche Videos, von denen ich spreche würde zwar nicht von der Bild aber durchaus von Youtube und Konsorten zensiert.

Grüße
Chris

Da du das nicht planen kannst, musst du wohl a) prophylaktisch eine ausreichende Hardware einplanen, sodass es sich wirtschaftlich lohnt, und b) hoffen, dass der Server hält. Ein Caching von 30 Sekunden ist sicher nicht verkehrt und wird dir die Last bereits ordentlich verteilen und gleichzeitig höchste Aktualität bieten.

Hm. Bei Domain-Factory kann man für solche Zwecke einen Überlastschutz vereinbaren, das heißt, die weisen entweder mehr Ressourcen zu oder - wenn es ganz arg kommt - ziehen den Auftritt auf eine eigene Umgebung um. Das geht recht schnell, kostet aber auch ein wenig extra. Ich habe es einmal gebraucht, die Preise waren sehr fair, soweit ich mich erinnere. Man kann auch "vorbestellen", wenn man zum Beispiel weiß, dass heise etwas in der nächsten c´t bringt.

Soll jetzt keine Werbung sein, mit diesem Provider habe halt ich meine Erfahrungen gemacht. Alle anderen, mit denen ich Erfahrung habe (bislang Strato, 1blue, 1&1, Kontent und t-online) bieten sowas zumindest nicht so aktiv an, dass ich es gesehen hätte.

Eine Alternative sind sicherlich die eher kleineren Anbieter, wie vielleicht manitu, iNet Robots oder die Firma von Leo Unglaub, hier könnte ich mir vorstellen, dass die auch flexibel auf solche Situationen reagieren können.

okay, danke für eure Hinweise, aber die entsprechende Hardware mal vorausgesetzt, packt TL so einen massiven Ansturm, ja?

Da man nie weiß, wie groß der Ansturm wird, kann man das nicht sagen. TL wird eine sehr hohe Besucherzahl verkraften, v. a. bei entsprechender Hardware und Software (inkl. Caching), aber irgendwann klappt halt der Server (nicht direkt TL) zusammen.

ok, ich werd mal konkret: was muss gegeben sein, damit TL 300 Seitenaufrufe pro Sekunde abfeuern kann und davon sehr viele Aufrufe von selbst gehosteten Videos?

Videos haben nichts mit TL zu tun. Dafür ist der Webserver (oder Stream-Server) zuständig. Der Player wird auf der Seite eingebunden, der Browser ruft dann das Video im Player ab.

ehm ja, schon klar, aber es geht ja im prinzip summarisch um hardwareanforderungen, die sich diese applikationen teilen müssen... deswegen hab ich das ja zusätzlich genannt, weil ich das überhaupt nicht einschätzen kann.

Hiho!

Ich sag's mal ganz profan: Ich glaub nicht, das es wirtschaftlich ist, sich gegen das "slashdotten" - also den urplötzlichen Anstieg der Aufrufe - durch Hardware-Vorhaltung zu schützen! Ist ja nicht nur die Hardware, sondern wenn es um den Bereich geht, von dem du sprichst, eine ganze Infrastruktur!

- Internetanbindung, da ist es mit 2 MBit nicht mehr getan, wenn die Videos streamen willst, brauchst du reichlich
- Trennen von Webserver, Datenbankserver, Videoserver, Revers Proxy auf verschiedene Maschinen.
- Aufteilen der Datenbank auf verschiedene Platten
- Load Balancer
- CDN

Und das alles für ein "vielleicht passiert mal was"?

Ich weiß nicht - für "irgend eine Künstlerseite" würde ich das nicht tun - nur wenn es abzusehen ist!

Wenn man den Thread hier aufmerksam liest, dann liest man auch, wo wohl das Bottleneck von TL ist: Bei den Datenbankabfragen, das werden wohl zu viele! Bei mySQL kann man da aber auch einen Proxy zwischen schalten. Was darüber hinaus geht, hieße den Core von TL anzupassen!

TL ist ein gutes, schlankes, flinkes System - aber ich bezweifle, dass es ein System für extreme Lasten ist! Das kann man mit Hardware abfangen, aber irgendwann stößt das an seine Grenzen, dann muss was speziell auf das Problem angepasstes her!

Und wann diese Grenze erreicht ist, ist sehr spezifisch von der Seite um die es geht abhängig - nicht nur von der Hardware, sondern wirklich davon, wie die Seite gestaltet ist, wie stark sie sich verändernde Inhalte besitzt, wie gut ein Caching greifen kann, ect.

Die Frage "Ich hab da 'ne Seite, und die bekommt vielleicht mal 100.000 Hits pro Stunde, kann das TL?" ist in der Form nicht seriös beantwortbar!

Mal so einen Rahmen einer ganz persönlichen, wenig fundierten Einschätzungen bei 1.000.000 Hits pro Stunde:

- Eine rein statische Seite, also HTML-Files und Bilder ausliefern: Kein Problem, das können Webserver!
- TL ohne "dynamische Inhalte", also Inhalte die bei jedem Aufruf anders sind: Ein vorsichtiges Ja, müsste gehen!
- TL, aber sich bei jedem Aufruf ändernde Inhalte: Wird langsam knapp! Fetter Server muss her!
- TL mit eigener Anwendung, viele Extensions, die eigene DB-Aufrufe generieren, nichts cachebares dabei: Sehr eng!
- TL, sich ständig ändernde Inhalte, und Videostreaming, und DB auf einer Maschine: Wird langsam zu viel für eine Maschine!

Aber belehrt mich eines besseren! Maschinen mit 64GB RAM und 24 Kernen kenne ich nur als Basis von VMWare, habe noch nie auf sowas einen Webserver betrieben - leider! Und sowas schaufelt schon erstaunlich was an Daten weg!

Tschüss
Marcus (aka Tiggr)

Hallo Marcus... endlich mal eine konkretere Aussage von jmd. hier... Danke :)

Zitat:

---

Und das alles für ein "vielleicht passiert mal was"?

---

Nein, die Frage ist nicht ob vielleicht mal was passiert, sondern ob es häufiger passiert. Denn die ganze Idee wurde ja von der Bild selbst an mich herangetragen. Ich muss nur überlegen wie das ganze am besten umgesetzt wird.

Zitat:

---

Die Frage "Ich hab da 'ne Seite, und die bekommt vielleicht mal 100.000 Hits pro Stunde, kann das TL?" ist in der Form nicht seriös beantwortbar!

---

Da die Seite noch nicht konzeptioniert wurde, kann ich nicht mehr sagen als Künstlerseite. Meines Erachtens nach ist damit aber auch alles gesagt, was nötig ist. Was soll einen da schon erwarten? Neben statischen Inhalten (Galerie, Videos Texte) vielleicht noch ein Gästebuch oder wenns hoch kommt sowas wie ein Blog.

Gut, der Bottleneck von der Bandbreite her wird jedenfalls das Video sein, und wenn eine Kommentarfunktionalität mit angeboten werden soll wirds auf jeden Fall dynamisch.

Zunächst zur Infrastruktur. Ein Freund von mir betreibt ein relativ großes RZ und setzt VMWare dabei ein. Für Hochleistungsinfrastruktur wäre gesorgt. Auf einer virtuellen Maschine, die flexibel jederzeit beliebig vergrößert werden kann, ist eine Aufteilung in Web-, Datenbank- und Videoserver ja nicht nötig, oder? Das mit einem CDN müsste ich noch checken.
Aber davon abgesehen interessiert mich also nur noch TL an sich.
Müsste man Modifikationen vornehmen? Wenn ja welche?
Ich könnte mir vorstellen TL zB. mit einem APC Cache aufzubohren. Zum einen könnte man damit ganz profan den Frontend-Cache in den Arbeitsspeicher verlagern. Zum anderen könnte man aber bei dynamischen Seiten auch die vorhandenen Datenbankinhalte cachen (Array A) und gleichzeitig die neu hinzukommenden, usergenerierten Datenbankeinträge abfangen und solange nur in den APC Cache schreiben (Array B) und dort gleichzeitig abrufbar machen, bis weniger Besucher auf der Seite sind. Dann ganz entspannt mit einem prepared statement Array B mit den neuen Datenbankeinträgen in die Datenbankeintrag schieben und gleichzeitig Array A einmal leeren und wieder frisch befüllen.

Ich weiß jetzt nicht spontan was man noch machen könnte, aber es klingt jedenfalls alles nach Arbeit. Ist die in einer solchen Hochleistungsserverumgebung überhaupt nötig?

Zitat:

---

Zitat von Tiggr

[…]
- Trennen von Webserver, Datenbankserver, Videoserver, Revers Proxy auf verschiedene Maschinen.
- Aufteilen der Datenbank auf verschiedene Platten
[…]
Wenn man den Thread hier aufmerksam liest, dann liest man auch, wo wohl das Bottleneck von TL ist: Bei den Datenbankabfragen, das werden wohl zu viele! Bei mySQL kann man da aber auch einen Proxy zwischen schalten. Was darüber hinaus geht, hieße den Core von TL anzupassen! […]

---

Ich halte es für einen Fehler, die Datenbank auszulagern (gibt wenige Ausnahmen). Dadurch erhöht sich nur die Latenz bei DB-Requests. Ausnahme: Der DB-Server ist direkt mit einer fetten Bandbreite und einer ordentlichen Konfiguration an den Webserver angeschlossen. Dann kannst du aber die DB direkt im Webserver betreiben und einfach die Rechenkerne entsprechend zuordnen.

Zitat:

---

Zitat von Tiggr

TL ist ein gutes, schlankes, flinkes System - aber ich bezweifle, dass es ein System für extreme Lasten ist! Das kann man mit Hardware abfangen, aber irgendwann stößt das an seine Grenzen, dann muss was speziell auf das Problem angepasstes her!

---

Definiere extreme Lasten. Ich denke, dass TL (genauer: der Server bei einem Aufruf über TL) weit höhere Lasten aushält als viele andere CMS. Solltest du wirklich in Lastenbereiche von Webschwergewichten kommen (was erst nach vielen Monaten, eher Jahren der Fall sein wird und auch vorher Weise abzusehen ist), wirst du nicht um eine händische Programmierung herumkommen.

Zitat:

---

Zitat von Tiggr

- TL ohne "dynamische Inhalte", also Inhalte die bei jedem Aufruf anders sind: […]

---

Du meinst wohl eher gleich (also Inhalte bleiben gleich) ;)

Zitat:

---

Zitat von chris

Gut, der Bottleneck von der Bandbreite her wird jedenfalls das Video sein, und wenn eine Kommentarfunktionalität mit angeboten werden soll wirds auf jeden Fall dynamisch.
[…]
Auf einer virtuellen Maschine, die flexibel jederzeit beliebig vergrößert werden kann, ist eine Aufteilung in Web-, Datenbank- und Videoserver ja nicht nötig, oder? Das mit einem CDN müsste ich noch checken.
[…]
Ich könnte mir vorstellen TL zB. mit einem APC Cache aufzubohren.
[…]
Ist die in einer solchen Hochleistungsserverumgebung überhaupt nötig?

---

Selbst wenn du Kommentare einsetzt, kannst du trotzdem eine gewisse Cachezeit voraussetzen. Allerdings müsste dann die Pagination mit einberechnet werden, weiß spontan nicht, wie TL sich da verhält.

Auch auf einer VM sind separate Medienserver sinnvoll – ein Server kümmert sich um das "Tagesgeschäft" (Website + DB), der andere (oder mehrere, eben CDN) um Videos, evtl. auch Bilder etc. Andreas Schempp hat mal eine CDN-Extension geschrieben, die kannst du dir ja mal anschauen (sollte natürlich auch mit nur einem extra Medienserver gehen).
Wenn es sicher zu bestimmten Zeiten zu höheren Lasten kommen kann, dann lagere datenintensive Elemente (Videos, Bilder, Audio) aus.

Wegen APC: Es sollte allein reichen diesen zu aktivieren, der kompiliert ja auch die PHP-Dateien vor. Ansonsten müsstest du erstmal gar nichts weiter machen. Erst wenn der Server in die Knie geht oder knapp dran vorbei ist, kannst du überlegen, was du noch verbessern kannst.

Und nochmal: Ob Hochleistungsrechner oder nicht, Optimierungen hängen immer von der zu erwartenden Last ab. Und der gemeine Rootserver langweilt sich, d. h. den kann man schon ordentlich zuballern, bis der mal schlapp macht (Shared Server verkraften ja auch Unmengen von unzusammenhängenden Anfragen).

Zitat:

---

Solltest du wirklich in Lastenbereiche von Webschwergewichten kommen (was erst nach vielen Monaten, eher Jahren der Fall sein wird und auch vorher Weise abzusehen ist), wirst du nicht um eine händische Programmierung herumkommen.

---

Nun hab ich ja am Beispiel einer Künstlerseite erläutert, bei dem klar ist, dass es niemals ein Webschwergewicht wird, bei dem es aber ein oder zweimal pro Jahr für ein paar Stunden richtig wummst, wenn der entsprechende Skandal auf der Bildstartseite steht.

Zitat:

---

Selbst wenn du Kommentare einsetzt, kannst du trotzdem eine gewisse Cachezeit voraussetzen. Allerdings müsste dann die Pagination mit einberechnet werden, weiß spontan nicht, wie TL sich da verhält.

---

Oh, an die hatte ich noch gar nicht gedacht... stimmt.

Zitat:

---

Auch auf einer VM sind separate Medienserver sinnvoll – ein Server kümmert sich um das "Tagesgeschäft" (Website + DB), der andere (oder mehrere, eben CDN) um Videos, evtl. auch Bilder etc.

---

Ehm, wieso ist das sinnvoll? Der virtuelle Rechenknecht kann doch flexibel und beliebig befeuert werden (load Balancing). Oder meinst du dass pure CPU Kraft gar nicht das Argument ist? Denn von den wenigen Stoßzeiten abgesehen würde sich ein extra Medienserver dermaßen langweilen, dass die zusätzlichen Kosten für ihn nicht wirklich lohnen.

Zitat:

---

Andreas Schempp hat mal eine CDN-Extension geschrieben, die kannst du dir ja mal anschauen (sollte natürlich auch mit nur einem extra Medienserver gehen).

---

Okay, da werf ich mal nen Blick.

Zitat:

---

Wegen APC: Es sollte allein reichen diesen zu aktivieren, der kompiliert ja auch die PHP-Dateien vor.

---

Ja ein bisschen bringt es sicher, aber die Wurst wird das nicht vom Brot ziehen.

Zitat:

---

Ansonsten müsstest du erstmal gar nichts weiter machen. Erst wenn der Server in die Knie geht oder knapp dran vorbei ist, kannst du überlegen, was du noch verbessern kannst.

---

Aber dann ist es ja zu spät :eek:

Zitat:

---

Zitat von chris

Ehm, wieso ist das sinnvoll? Der virtuelle Rechenknecht kann doch flexibel und beliebig befeuert werden (load Balancing). Oder meinst du dass pure CPU Kraft gar nicht das Argument ist? Denn von den wenigen Stoßzeiten abgesehen würde sich ein extra Medienserver dermaßen langweilen, dass die zusätzlichen Kosten für ihn nicht wirklich lohnen.

---

Wie skalierbar ein Server ist, ist irgendwann wurscht, denn irgendwann hast du halt die Grenze erreicht. Du kannst auch bei einer VM nicht beliebig an der Leistungsschraube drehen, da drunter liegt immernoch echte Hardware. CPU ist übrigens nur die halbe Miete, RAM ist genauso wichtig, aber das nur nebenbei.

Wie gesagt, wenn zu erwarten ist, dass es irgendwann zu hoher Belastung kommt, wirst du um den Medienserver froh sein. Wenn du das Risiko eingehen willst, kannst du das gerne machen, der Server muss ja nicht bei großem Ansturm zusammenbrechen. Auch wenn die BILD-Startseite auf dich verlinkt, heißt es noch lange nicht, dass "genug" Besucher kommen, um den Server ins Schwitzen zu bringen.
Wenn du keinen extra Server dafür anmieten willst, kannst du ja auf Anbieter zurückgreifen, die sich nur um ausgelagerte Medienserver und CDN kümmern (Akamai, Amazon S3, …). Da kriegst du passende Preise für eine ordentliche Leistung.

Zitat:

---

Zitat von chris

Ja ein bisschen bringt es sicher, aber die Wurst wird das nicht vom Brot ziehen.

---

Es gibt dir aber schonmal ein ordentliches Butterbrot ;). Weitere Optimierungen mit APC etc. lohnen sich erst, wenn schon andere Möglichkeiten ausgereizt sind.

Zitat:

---

Zitat von chris

Aber dann ist es ja zu spät

---

Ja und nein. Wenn du siehst: Ah, jetzt geht es an die Belastungsgrenze, solltest du natürlich schon einen Plan haben (oder wenn es bereits zu spät ist). Fakt ist aber: Du kannst dir nie sicher sein, wie es laufen wird, und dann ist es einfach eine Frage der Ökonomie, welche Maßnahmen zu ergreifst.

Du könntest z. B. sagen: Ok, jetzt macht der Server langsam schlapp, also nimmst du mal temporär den Druck vom Server und schaltest eine statische Seite, während du den Rest lahmlegst. Nach kurzer Zeit (wenn der Server wieder RAM freigeschaufelt hat und Temperatur in den Griff bekommen hat) schaltest du wieder auf die Live-Version.

Wichtig ist dann immer, was du aus der Sache lernst: Wo muss ich jetzt was ändern, damit ich in Zukunft nicht danebensitzen und Türsteher spielen muss? Muss ich überhaupt was ändern? Wo liegen die Probleme? Wann ist solch ein Problem wieder zu erwarten? Unter welchen Umständen und Voraussetzungen?

Ein bisschen Risiko musst du immer haben, es sei denn, du hast unendlich Ressourcen zur Vefügung. Aber wenn du dann ein RZ "nur für den Fall" hast, wirds irgenwann langweilig – und natürlich teuer ;).

Zitat:

---

CPU ist übrigens nur die halbe Miete, RAM ist genauso wichtig

---

Ich denke mal wenn ein Rechenzentrum über die entsprechenden Blade-Monster verfügt, dann wird RAM noch vor der Kernanzahl das geringste Problem sein. Vielleicht sind dann eher die Bandbreiten der Speicher-Anbindungen relevant um den ganzen Quatsch schnell genug hin und her schaufeln zu können.
Aber die genauen Verhältnise zwischen den ganzen Anforderungen wird man wohl tatsächlich erst unter richtiger Last beurteilen können, da hast du sicherlich Recht.
Ich frage nur weil es ja sein könnte, dass jmd. sagen kann, wo und bei welcher Belastung der Bottleneck zu vermuten ist.
Nichtsdestotrotz hab ich mal auf einer Testumgebung das CDN Plugin ausprobiert... super Sache. Gefällt mir sehr gut.
Da kann man sich ja schon fast ne alte Gurke als Webserver per DynDNS am billig DSL ins Wohnzimmer stellen und die Mediendateien von Amazon abholen lassen. Könnte Wetten für 99% aller Webprojekte reicht das :D

Aber zurück zu meinem Luxusproblem: bei dieser CDN Extension fehlt eigentlich nur noch ein Threshhold-Parameter, mit dem man festlegen kann, ab welcher Last das CDN aktiv werden soll :) ... Ab einem sehr hohen Wert könnte man dann auch noch das gesamte System auf eine statische Seite umleiten, die als zusätzliche Adresse bei den CDN Parametern auf der Rootseite angegeben wird, das wärs doch oder?

Ach ja a propos Umleiten, da fällt mir ein, htaccess an sich ist ja auch ne mittelmäßige Handbremse. Besser wärs ja die Angaben in einem VirtualHost zu übertragen und die htaccess Dateien rauszuschmeissen, denn sonst muss innerhalb des Document Root jedes Verzeichnis nach dhtaccess Dateien abgegrast werden, was bei vielen Requests laut diesem Test wohl an die 7% Performance kosten kann.

Mal was anderes, du nennst dich doch wohl nicht FloB wegen dieses unsäglichen Haarscheideaufsatzes für den Staubsauger... das ich auch noch zufälligerweise seit 15 Jahren benutze? :D

Nein, Staubsauger-"Extension" hat damit nichts zu tun ;).

Zum HTACCESS-Problem: Wenn dir Performance lieb is, dann nutze lighttpd oder nginx als Server, nicht Apache. Letzterer ist zwar stärker konfigurierbar, aber mit den anderen sollte TYPOlight problemlos voll funktionsfähig sein (lighttpd könnte die bessere Wahl sein).

Edit: Achja, zu Anfragen bezüglich der CDN-Erweiterung kontaktierst du am besten Andreas direkt.

Vielleicht hast du ja Haar-Extensions und dein Nick ist in Wirklichkeit ein subtiler Hilferuf nach der Staubsauger-Extension :D

Interessante Diskussion bisher!

Eine Frage, die sich letztens bei einem Kunden gestellt hat:

Gibt es eine Möglichkeit, TYPOlight auf Applikationsebene zu clustern?

Also nicht einfach eine VM in einen VMWare-Cluster zu betreiben, sondern den Cluster auf einem höheren Layer zu definieren - bzw. macht das aus Sicht der TL-Arichtektur überhaupt Sinn, das System so zu clustern? Und wenn nicht, wieso nicht?

Die Separierung von Media und Core-Server macht ja schonmal Sinn, wenn da ordentliche ESX drehen, braucht's wohl einiges bis die Seite in die Knie geht.

Ich habe zwar keinen direkten Bedarf daran, aber mich würde auch mal interessieren, ob jemand schonmal TL auf mehreren Servern hinter einem Loadbalancer betrieben hat, und ob dies technisch möglich ist (Stichwort Session Migration...).

Stefan

Hallo Stefan
Die Resonanz ist ja bisher nicht gerade grossartig :-)

Hat keiner das schonmal gemacht, oder eine Idee, ob das zu bewerkstelligen wäre das Ding zu clustern?

Genau dasselbe wie bei jeder anderen WebApp...

Zitat:

---

Zitat von andreas.schempp

Genau dasselbe wie bei jeder anderen WebApp...

---

Auf welche Frage ist das jetzt die Antwort?

Danke,
Stefan

Zitat:

---

Zitat von grambler

Hallo Stefan
Die Resonanz ist ja bisher nicht gerade grossartig :-)

Hat keiner das schonmal gemacht, oder eine Idee, ob das zu bewerkstelligen wäre das Ding zu clustern?

---

Hi!

Das ist für mich das Zeichen, dass es bisher noch keiner gemacht hat, weil es wohl noch nicht notwendig war. Ich habe die Anforderung bisher auch nicht, darum kann ich das verschmerzen. Muss man sich halt selbst drum kümmern, wenn es mal soweit sein sollte.

Stefan

Wir werden mit der Agentur, in der ich arbeite, im nächsten Monat eine Website mit TL erstellen die als Portal für Downloads dienen soll. Es steckt ein sehr großer Kunde dahinter den wir seit Jahren betreuen und dem einige sehr sehr große Shops gehören. Ich würde das nicht so betonen wenn ich mir nicht erhebliche Sorgen um die Zugriffszahlen machen würde!

Hier nochmal die Features:

- Loginseite die die restlichen Seiten schützt (somit also kein Caching möglich oder?)
- Einige tausend registrierte Benutzer
- Viele unterschiedliche Downloadarten (jpg's, pdf's, zip's)
- 25 Sprachen

Wenn ich mir die restlichen Beiträge in diesem Thread so durchlese haben hier wohl manche Erfahrungen mit Millionen PI's im Monat ;-) vielleicht könnt ihr mir trotzdem helfen.

Was wäre eurer Meinung nach die ersten Dinge auf die ich bei der Programmierung und Frontend-Entwicklung achten muss damit uns der Server nicht beim ersten Besucheransturm abraucht?

PS: Die Hardware ist nicht das Problem. Die haben ne kleine Serverlandschaft zur Verfügung aber ich will einfach auch bei Programmierung das beste rausholen damit die Seite noch schneller lädt...

Hab zwar keine Millionen PIs pro Monat, aber die Basics sollten allgemeingültig sein:

• Dateien in ein CDN auslagern, zumindest eigene Medienserver einrichten
• APC / andere Optimizer laufen lassen
• Browser-side caching aktivieren
• XHTML, CSS optimieren, einige Teile per AJAX nachladen lassen (z. B. Kommentare)
• JS / MooTools (falls verwendet) optimieren, nicht benötigte Bestandteile entfernen!
• Bilder optimieren! Ich sehe zu oft, dass eingebundene Bilder nicht für das Web optimiert werden. Spart Bandbreite und Prozessor-Cycles (v. a. wenn Bilder automatisch weiterverarbeitet werden). Für über das Web hochgeladene Bilder (z. B. von Besuchern oder Redakteuren) sollte serverseitig bereits eine Optimierung laufen
• Ein paar (für den jeweiligen Anwendungsfall) hochoptimierte Erweiterungen entwickeln und diese (soweit möglich) mit einem Caching versehen.
• PHP 5.3 + mysqlnd mit persistenter Verbindung laufen lassen – AFAIK gibt das bei häufigen DB-Verbindungen einen ordentlichen Geschwindigkeitsvorteil!
• Vernünftige Server-Konfiguration mit threaded server (apache2 nicht prefork) / fcgid.
• Und natürlich nur das Nötigste installiert und auf dem Server haben (z. B. auch nicht benötigte Core-Module entfernen, soweit möglich).

Ich denke, dass ich dir mit einigen Punkten hier nichts Neues verrate, aber das sind nunmal die Basics, die zu beachten schon erstaunlich viel Effekt auf die Performance hat.

Wenn es an Core-Optimierungen gehen soll – da sehe ich ein Bottleneck, an dem man mE ein paar Millisekunden herausholen kann: TL grast massiv das Dateisystem bei jedem Request ab. Da wäre es vielleicht sinnvoll, ein Caching bzw. einen Index der vorhandenen Dateien einzubauen. Dafür müsstest du aber sämtliche Stellen, die nach dem Vorhandensein von Dateien fragen, anfassen, und es ist die Frage, inwieweit das Dateisystem selber solche Anfragen cache'd und du mit "deinem" Cache nur den RAM vollballerst ohne einen wahren Effekt daraus zu bekommen – müsste man mal durchtesten.

Ansonsten kann ich dir jetzt spontan keine allgemeinen Core-Optimierungen nennen – hängt halt alles davon ab, was genau ihr machen und wie sehr ihr den Core modifizieren wollt.


Edit: itk-* ist natürlich schwachsinn, threaded ist nur der "normale" Apache 2.2.

Einige Dinge in deiner Auflistung wusste ich noch nicht ;)
Danke dir dafür. Zum Glück bringt TYPOlight schon ein anständiges Caching mit! Das macht die Sache um einiges leichter.

Ich melde mich sobald die Seite online ist.

Zitat:

---

Zitat von jared

Einige Dinge in deiner Auflistung wusste ich noch nicht ;)
Danke dir dafür. Zum Glück bringt TYPOlight schon ein anständiges Caching mit! Das macht die Sache um einiges leichter.

Ich melde mich sobald die Seite online ist.

---

@jared: Was mich mal interessieren würde: ist das Projekt mittlerweile online? Und gibt es erste Erfahrungen?

Ja die Seite ist mittlerweile online :-) Und ich bin sehr zufrieden.

Wir haben in diesem Jahr mehrere sehr große Websites online gestellt und bisher war das Frontend noch keine Schwachstelle. Lediglich das Backend gibt irgendwann auf wenn es zuviele Ajax Calls durchführen muss. Aber dann schalten wir das JS einfach aus.

Selbst bei den Seiten mit mehr als 5000 Seiten/Unterseiten, verteilt auf über 30 Sprachen läuft alles super. Der Server muss einfach alles verkraften und bei den http_requests sollte man nicht übertreiben.

Zitat:

---

Zitat von jared

Ja die Seite ist mittlerweile online :-) Und ich bin sehr zufrieden.

Wir haben in diesem Jahr mehrere sehr große Websites online gestellt und bisher war das Frontend noch keine Schwachstelle. Lediglich das Backend gibt irgendwann auf wenn es zuviele Ajax Calls durchführen muss. Aber dann schalten wir das JS einfach aus.

Selbst bei den Seiten mit mehr als 5000 Seiten/Unterseiten, verteilt auf über 30 Sprachen läuft alles super. Der Server muss einfach alles verkraften und bei den http_requests sollte man nicht übertreiben.

---

Cool! Danke für die Info

Ich hab ehrlich gesagt sehr wenig Angst vor großen Websites: http://www.hetzner.de/de/hosting/pro...otserver/eq10/ :cool:

Bei unseren Größenordnungen ist Clustering nur für Hochverfügbarkeit nötig, aber Performance dürfte durch einen sauber aufgesetzten Server kein großen Thema sein.

Zitat:

---

Zitat von andreasisaak

Ja die Seite ist mittlerweile online :-) Und ich bin sehr zufrieden.

Wir haben in diesem Jahr mehrere sehr große Websites online gestellt und bisher war das Frontend noch keine Schwachstelle. Lediglich das Backend gibt irgendwann auf wenn es zuviele Ajax Calls durchführen muss. Aber dann schalten wir das JS einfach aus.

Selbst bei den Seiten mit mehr als 5000 Seiten/Unterseiten, verteilt auf über 30 Sprachen läuft alles super. Der Server muss einfach alles verkraften und bei den http_requests sollte man nicht übertreiben.

---

hallo andreasisaak kannst du mal einen link dieser seite angeben?

ich würde gerne eine grösseres "eigenes" projekt umsetzen
ich denke ich würde es einfach mal riskieren und würde mich über ein erfahrungsaustausch freuen