TYPO4 erschienen - feature complete

Content Management System Typo3 in Version 4 erschienen

Heute erblickt Version 4.0 des freien Content Management Systems Typo3 das Licht der Welt. Kasper Skårhøj, Präsident der Typo3 Association, die die Weiterentwicklung des Typo3-Frameworks koordiniert, betrachtet das neue Release als einen Meilenstein in der Geschichte des Open-Source-CMS.

http://www.heise.de/newsticker/meldung/71795

http://www.typo3.com/

nur mal so am Rande, nach den ersten paar produktiv Einsätzen von T3 4.0...

Typo3 4.0 ist einfach nur geil geworden...

mit den Workspaces können jetzt geniale Workflow-Konzepte umgesetzt werden, Versioning funktioniert jetzt auch auf alten Debian-Woody-Kisten mit MySQL 3.irgendwas...

*yes*


OK, nachteil das TER will deutlich mehr Speicher auf *sehr* schmalbrüstigen Servern sollte Typo3 4.0 wirklich nicht mehr eingesetzt werden...

Was wäre denn eine sinnvolle Ausstattung für einen wenig besuchten Server?

ich hab eine Testinstallation auf einem P3@750MHz mit 512MB laufen... das geht im LAN mit 3-4 gleichzeitigen Zugriffen noch OK, sind manchmal dauerts einwenig bis alles kommt (wobei ich hier lokal mit mod_php arbeite, die Fielrechte sind mir egal und es ist etwas Ressourcenschonender)

Produktiv setze ich das i.A. nur mit php-cgi ein und da sollte es schon etwas mehr CPU sein. mit ausreichend Speicher (4GB) läuft das wunderbar auf einem Shared-Host mit Dual P3@1200MHz da laufen mehrere Typo3-instanzen drauf (OK, man merkt wenn der Rechner mal was zu tun hat aber sonst ist das auch nch akzeptabel) (gut, die Kiste ist auch mit einem USCSI-320 RAID5 ausgestattet... bei einem IDE-Server mag das etwas zäher werden..

beide Varianten jeweils mit mysql auf dem gleichen host!

Wenn es heftig wird sollte man im 1. Schritt mysql auf einen anderen Host auslagern und da eine fixe-LAN-leitung einsetzen, das bringt schon mal was
und dann Dicke CPU mit *viel* Speicher, schneller Platte und mysql auch auf eine Schnelle Platte. Durch das Caching gewinnt man sehr viel... auf kleineren Rechnern kann eine ungecachte Seite schon mal ein paar Sekunden brauchen, gecached dann in <<1Sek.

TeXpert schrieb:

ich hab eine Testinstallation auf einem P3@750MHz mit 512MB laufen... das geht im LAN mit 3-4 gleichzeitigen Zugriffen noch OK, sind manchmal dauerts einwenig bis alles kommt (wobei ich hier lokal mit mod_php arbeite, die Fielrechte sind mir egal und es ist etwas Ressourcenschonender)

Zum Vergrößern anklicken....

... was wieder meinen Eindruck bestätigt dass Typo[34] Bloatware ist.
3-4 Verbindungen LOL

naja, Reddot möchte ich auf einem P3 750 auch nicht nutzen müssen mit mehr Speicher und etwas schnellerer Platte sollten hier auch problemlos deutlich mehr gehen... aber zum templatetest mit 4-Entwicklern reicht das. mit mehr leuten hab ich den noch nie belastet...

Geschwindigkeit ist immer relativ, klar ist kein mini-CMS ... (hat das jemand behauptet?) das Hauptproblem bei meinem P3 ist, dass da alles auf einer langsamen Platte (5400Umin) läuft, also Apache, System, MySQL... aber das gilt halt auch für die gängigen Billig-Rootserver... *dafür* ist T3 wohl eher nicht geeignet.

*aber* auf richtigen Maschinen: Problemlos. ich hab heute Vomi in einem Intranet auf einem Dual P3, 1000 mit 4GB Ram das Interne Portal von 3.7 auf 4 gebracht, hier gehts um einige Tausen PIs am Tag (in der Arbeitszeit) und das ist akzeptabel von der Reaktionszeit... System (Woody), DB und Apache 1.3 liegen auf einem Host, mit 2 raid-5 Gruppen in USCSI160 und USCSI320, einmal für System und DB und einmal für die htdocs (und php) da kann ich nicht meckern...

das ganze läuft mit 40 Redakteuren und da ändert sich sehr häufig etwas im Content....

Sorry, aber diesen Kommentar Bloatware bekommt man immer nur von Leuten zu hören, die damit entwder noch nie gearbeitet haben, eine Site mit 3 Seiten Pflegen oder oder oder...

Kurz: ein Low-Level-Server *ist* nicht geeignet für eine große T3-Präsenz... aber das gilt für jedes CMS in dieser Größe... denn ein winziger Server auf IDE Basis kann bei Dynamischen Setien gar nicht genug Anfragen bewältigen.

TeXpert schrieb:

mit mehr Speicher und etwas schnellerer Platte sollten hier auch problemlos deutlich mehr gehen

Zum Vergrößern anklicken....

Deshalb sagte ich "Bloatware". Der Indikator ist der Ruf nach besserer HW.

Denn ein PIII 750 hat nach meiner Erfahrung genug Power um ~200 Anfragen/min problemlos zu beantworten, und ich rede von dynamischen per PHP generierten Seiten, die per Abfrage zu einer ebenfalls auf demselben Server laufenden MySQL DB generiert wurden.

Nur eben nicht wenn Typo3 verwendet wird, dann sinkt die Zahl rapide.

TeXpert schrieb:

*aber* auf richtigen Maschinen: Problemlos.

Zum Vergrößern anklicken....

"Auf richtigen Maschinen" - wo fängt das bei dir an? Was sind die Rechner die d.E. nicht darunter fallen, Spielzeuge? Wie hat das Internet vor 5 Jahren funktioniert als es noch keine "richtige Maschinen" gab?

TeXpert schrieb:

in einem Intranet auf einem Dual P3, 1000 mit 4GB Ram das Interne Portal von 3.7 auf 4 gebracht, hier gehts um einige Tausen PIs am Tag (in der Arbeitszeit) und das ist akzeptabel von der Reaktionszeit... System (Woody), DB und Apache 1.3 liegen auf einem Host, mit 2 raid-5 Gruppen in USCSI160 und USCSI320, einmal für System und DB und einmal für die htdocs (und php) da kann ich nicht meckern...

Zum Vergrößern anklicken....

Internet, PIII-600, 512MB, DMA-66 IDE Platten, ~21.000 PI/d
MySQL DB Gesamtvolumen ca. 512MB

Load avg < 0.1

TeXpert schrieb:

Sorry, aber diesen Kommentar Bloatware bekommt man immer nur von Leuten zu hören, die damit entwder noch nie gearbeitet haben, eine Site mit 3 Seiten Pflegen oder oder oder...

Zum Vergrößern anklicken....

Mitnichten mon ami (und bitte in Zukunft keine solchen Unterstellungen - von wg. "immer" und implizit "spielen noch im Sandkasten").

TeXpert schrieb:

Kurz: ein Low-Level-Server *ist* nicht geeignet für eine große T3-Präsenz...

Zum Vergrößern anklicken....

ACK

TeXpert schrieb:

aber das gilt für jedes CMS in dieser Größe... denn ein winziger Server auf IDE Basis kann bei Dynamischen Setien gar nicht genug Anfragen bewältigen.

Zum Vergrößern anklicken....

Dem muss ich widersprechen. Wir reden hier von einem CMS, nicht von Content-Streaming oder sowas wie Google-maps... also echt keine Killer-App bzgl. Resourcen.

Das Admin/Redaktionsfrontend von T3 ist gut, aber die Abfrage des Content ist schlichtweg zu aufwendig implementiert. Wenn man sich die SQL Queries ansieht (ich habe das vor ca. 1 Jahr zuletzt gemacht, aber deine Specs geben wenig Hoffnung auf Besserung): Eyecancer!

Wenn sowas wie "SELECT * FROM * IN DATABASE LIKE '%' HOST LIKE'%' WHERE 1" legales SQL wäre - Typo3 würde es verwenden :mrgreen:

Aber bevor das hier in peinliche "mein Server hat dickere Speicher" Diskussionen ausartet:
mein Anliegen bei der Bezeichnung "Typo3 ist Bloatware" zielt darauf dass T3 sich in der Entwicklung lange nur an Features orientiert hat und damit zu dem geworden ist was es ist: ein resource-hog.
Wie toll T3 Sites skalieren merkt man immer dann wenn eine davon aus irgendeinem Grund bei populären Diensten genannt wird (sf.net, heise.de, ...): E404 für die nächsten 24h

Dies mit bessere HW zu kontern hat noch nie funktioniert denn der Preis für HW steigt ab einem bestimmten Leistungslevel rasant, wogegen der Hirnschmalz investiert in bessere Indizierung der DB bzw. Queries wesentlich billiger wäre...

panamajo schrieb:

TeXpert schrieb:

mit mehr Speicher und etwas schnellerer Platte sollten hier auch problemlos deutlich mehr gehen

Zum Vergrößern anklicken....

Deshalb sagte ich "Bloatware". Der Indikator ist der Ruf nach besserer HW.

Zum Vergrößern anklicken....

naja, hast Du schon mal einen Blick auf andere große CMS geworfen? ...

*richtig* Spass macht sowas auf kleinen Maschinen nicht...

Denn ein PIII 750 hat nach meiner Erfahrung genug Power um ~200 Anfragen/min problemlos zu beantworten, und ich rede von dynamischen per PHP generierten Seiten, die per Abfrage zu einer ebenfalls auf demselben Server laufenden MySQL DB generiert wurden.

Zum Vergrößern anklicken....

das ist wieder alles relativ, *wie* sehen die Anfragen aus... *welches* Bussystem ...

Nur eben nicht wenn Typo3 verwendet wird, dann sinkt die Zahl rapide.

Zum Vergrößern anklicken....

schon mal andere große CMS mit vergleichbarer Funktionalität getestet?

Der Hauptnachteil bei T3 ist immer noch die Fixierung auf einen Server, langfristig sollte das Backend locker auf einer anderen maschine laufen können, denn das BE frisst sehr viel Leistung (ok, es sit aber druch das komplexe Layout *so* einfach, dass ich jeder Sekretärin in 5 Minuten zeige, wie Inhalte damit verwaltet werden...

Auch haben Reddot und Co noch einen Vorteil beim Export von Statischen Seiten (Stage/Live)Trennung... da ist mit T3 zur Zeit nur statischer Code möglich.

TeXpert schrieb:

*aber* auf richtigen Maschinen: Problemlos.

Zum Vergrößern anklicken....

"Auf richtigen Maschinen" - wo fängt das bei dir an?

Zum Vergrößern anklicken....

das ist immer Aufgaben und Anfragensensitiv, heute, für eine *richtige*[tm] Webseite setze ich IDR Dual-CPU (ab 1Ghz) Maschinen mit entsprechendem IO-interface ein.

Was sind die Rechner die d.E. nicht darunter fallen, Spielzeuge? Wie hat das Internet vor 5 Jahren funktioniert als es noch keine "richtige Maschinen" gab?

Zum Vergrößern anklicken....

vor 5-10 Jahren hatte ich Webseiten nicht auf PCs sondern auf Sun Sparc Station, Sun E oder dicken HP-UX-Maschinen laufen, da hat niemand an einen "PC" als Webserver gedacht. Und heute sieht das ähnlich aus.

Eine produktiv Maschine muss *so* ausgelegt sein, dass ich die DB und das Dateisystem während des Betriebs spiegeln kann, ohne dass die Kiste in die Knie geht, versuch *das* mal auf einer IDE-Bastellösung...

TeXpert schrieb:

Sorry, aber diesen Kommentar Bloatware bekommt man immer nur von Leuten zu hören, die damit entwder noch nie gearbeitet haben, eine Site mit 3 Seiten Pflegen oder oder oder...

Zum Vergrößern anklicken....

Mitnichten mon ami (und bitte in Zukunft keine solchen Unterstellungen - von wg. "immer" und implizit "spielen noch im Sandkasten").

Zum Vergrößern anklicken....

ich korrigiere mich: s/man/ich/

TeXpert schrieb:

Kurz: ein Low-Level-Server *ist* nicht geeignet für eine große T3-Präsenz...

Zum Vergrößern anklicken....

ACK

TeXpert schrieb:

aber das gilt für jedes CMS in dieser Größe... denn ein winziger Server auf IDE Basis kann bei Dynamischen Setien gar nicht genug Anfragen bewältigen.

Zum Vergrößern anklicken....

Dem muss ich widersprechen. Wir reden hier von einem CMS, nicht von Content-Streaming oder sowas wie Google-maps... also echt keine Killer-App bzgl. Resourcen.

Das Admin/Redaktionsfrontend von T3 ist gut, aber die Abfrage des Content ist schlichtweg zu aufwendig implementiert. Wenn man sich die SQL Queries ansieht (ich habe das vor ca. 1 Jahr zuletzt gemacht, aber deine Specs geben wenig Hoffnung auf Besserung): Eyecancer!

Zum Vergrößern anklicken....

Mooomen, Unterscheide bitte:
a/ mit Trennung Live/Stage und publish-Content arbeitem
b/ gecached dynamisch
und
c/ voll dynamisch.

a/ kann T3 leider nur eingeschränkt (voll statisch problemlos, halb statisch naja...) dann ist das CMS raus

b/ kann T3 sehr gut, dann ist die Last kaum höher als bei statischen Seiten (dass setzt aber vorraus, dass sich am Content nicht viel ändert, OK, wenn ich auf die "normale" Webseite schaue, dann siehts auch so aus )

c/ hier ist alles dynamisch, der Cache kann kaum zum Tragen kommen, aber genau *dafür* muss die Leistung da sein

(bei Hobbyseiten mag das anders sein, aber bei Unternehmenspräsenzen (Inter oder Intra)-net da steigt dir der Chef aufs Dach...)

Wenn sowas wie "SELECT * FROM * IN DATABASE LIKE '%' HOST LIKE'%' WHERE 1" legales SQL wäre - Typo3 würde es verwenden :mrgreen:

Zum Vergrößern anklicken....

sowas in der Art ist mir bis jetzt nur in einigen Extensions untergekommen der Core sieht mittlerweile recht nett aus.

Aber bevor das hier in peinliche "mein Server hat dickere Speicher" Diskussionen ausartet:
mein Anliegen bei der Bezeichnung "Typo3 ist Bloatware" zielt darauf dass T3 sich in der Entwicklung lange nur an Features orientiert hat und damit zu dem geworden ist was es ist: ein resource-hog.

Zum Vergrößern anklicken....

es kommt sicherlich auf die Einstellung an.. rechnest Du die Kapazität auf worst-case oder average-case ich plane wichtige Maschinen nach dem Worstcase..

Wie toll T3 Sites skalieren merkt man immer dann wenn eine davon aus irgendeinem Grund bei populären Diensten genannt wird (sf.net, heise.de, ...): E404 für die nächsten 24h

Zum Vergrößern anklicken....

ach komm, red keinen Stuss. mit einem entsprechenden heise.ddos oder der passenden /.-Menge sättige ich vorher schon die Router da kommt gar nicht genug bis zu T3 durch...

Dies mit bessere HW zu kontern hat noch nie funktioniert denn der Preis für HW steigt ab einem bestimmten Leistungslevel rasant,[/qutoe]

genau, Loadbalancer etc. sind völliger Dünnschiss und braucht kein Mensch.

wogegen der Hirnschmalz investiert in bessere Indizierung der DB bzw. Queries wesentlich billiger wäre...

Zum Vergrößern anklicken....

Zum Vergrößern anklicken....

FUD.

Sorry, aber klar, Du hast die große Ahnung und alle anderen sind doof.

*wenn* Du so toll bist, dann bau ein CMS, das die gleichen Funktionen hat und *so* toll ist wei Du sagst...

Was richtig ist, viele Extensions sind grausam (OK, es kann halt jeder was bauen...) und da findest Du grauenhaften Code, oder Extensions, die das gesamte Caching deaktivieren... *aber* das ist ncith T3.

TeXpert schrieb:

genau, Loadbalancer etc. sind völliger Dünnschiss und braucht kein Mensch.
[...]
Sorry, aber klar, Du hast die große Ahnung und alle anderen sind doof.

Zum Vergrößern anklicken....

Bei so viel Sachlichkeit verzichte ich weitere Beiträge. :evil: