Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

TYPO4 erschienen - feature complete

Alles rund um die Systemverwaltung, die Administration und Konfiguration Eures Linuxsystems

Moderator: Moderatoren

Antworten
Klaus-D. Wenger
Hacker
Hacker
Beiträge: 271
Registriert: 24. Dez 2004, 12:03
Wohnort: Bremen
Kontaktdaten:

TYPO4 erschienen - feature complete

Beitrag von Klaus-D. Wenger » 8. Apr 2006, 07:52

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/
OpenSUSE 11.2
- Eine einfache Lösung aus de.comp.lang.php.misc Date: Tue, 07 Oct 2003 20:03:32:
>> Wenn ihr PHP zu Dokumentationszwecken ausdrucken müsst, was verwendet
>> ihr dann?

Einen Drucker?

Werbung:
Benutzeravatar
TeXpert
Guru
Guru
Beiträge: 2166
Registriert: 17. Jan 2005, 11:22

Beitrag von TeXpert » 19. Apr 2006, 11:49

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...

Code: Alles auswählen

# to resolve all your problems, try this:
HOWTO='pack c5,41*2,sqrt 7056,unpack(c,H)-2,oct 115' && perl -le "print $HOWTO"
Ich beantworte keine Supportfragen per PM!

carsten
Guru
Guru
Beiträge: 1632
Registriert: 27. Jan 2004, 13:27
Wohnort: Mittelhessen

Beitrag von carsten » 25. Apr 2006, 09:05

Was wäre denn eine sinnvolle Ausstattung für einen wenig besuchten Server?
Intel DB65ALB3, Chipsatz B65, Celeron G540, 4GB, 1x1TB System, 2x 2TB SATA RAID1, SuSE 13.2 (noch)

Benutzeravatar
TeXpert
Guru
Guru
Beiträge: 2166
Registriert: 17. Jan 2005, 11:22

Beitrag von TeXpert » 25. Apr 2006, 19:46

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.

Code: Alles auswählen

# to resolve all your problems, try this:
HOWTO='pack c5,41*2,sqrt 7056,unpack(c,H)-2,oct 115' && perl -le "print $HOWTO"
Ich beantworte keine Supportfragen per PM!

Benutzeravatar
panamajo
Guru
Guru
Beiträge: 2587
Registriert: 12. Feb 2005, 22:45

Beitrag von panamajo » 25. Apr 2006, 20:39

TeXpert hat geschrieben: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)
... was wieder meinen Eindruck bestätigt dass Typo[34] Bloatware ist.
3-4 Verbindungen LOL

Benutzeravatar
TeXpert
Guru
Guru
Beiträge: 2166
Registriert: 17. Jan 2005, 11:22

Beitrag von TeXpert » 26. Apr 2006, 13:50

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.

Code: Alles auswählen

# to resolve all your problems, try this:
HOWTO='pack c5,41*2,sqrt 7056,unpack(c,H)-2,oct 115' && perl -le "print $HOWTO"
Ich beantworte keine Supportfragen per PM!

Benutzeravatar
panamajo
Guru
Guru
Beiträge: 2587
Registriert: 12. Feb 2005, 22:45

Beitrag von panamajo » 26. Apr 2006, 22:01

TeXpert hat geschrieben:mit mehr Speicher und etwas schnellerer Platte sollten hier auch problemlos deutlich mehr gehen
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 hat geschrieben:*aber* auf richtigen Maschinen: Problemlos.
"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 hat geschrieben: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...
Internet, PIII-600, 512MB, DMA-66 IDE Platten, ~21.000 PI/d
MySQL DB Gesamtvolumen ca. 512MB

Load avg < 0.1 :)
TeXpert hat geschrieben: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...
Mitnichten mon ami (und bitte in Zukunft keine solchen Unterstellungen - von wg. "immer" und implizit "spielen noch im Sandkasten").
TeXpert hat geschrieben:Kurz: ein Low-Level-Server *ist* nicht geeignet für eine große T3-Präsenz...
ACK
TeXpert hat geschrieben: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.
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...

Benutzeravatar
TeXpert
Guru
Guru
Beiträge: 2166
Registriert: 17. Jan 2005, 11:22

Beitrag von TeXpert » 27. Apr 2006, 11:39

panamajo hat geschrieben:
TeXpert hat geschrieben:mit mehr Speicher und etwas schnellerer Platte sollten hier auch problemlos deutlich mehr gehen
Deshalb sagte ich "Bloatware". Der Indikator ist der Ruf nach besserer HW.
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.
das ist wieder alles relativ, *wie* sehen die Anfragen aus... *welches* Bussystem ...
Nur eben nicht wenn Typo3 verwendet wird, dann sinkt die Zahl rapide.
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 hat geschrieben:*aber* auf richtigen Maschinen: Problemlos.
"Auf richtigen Maschinen" - wo fängt das bei dir an?
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?
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 hat geschrieben: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...
Mitnichten mon ami (und bitte in Zukunft keine solchen Unterstellungen - von wg. "immer" und implizit "spielen noch im Sandkasten").
ich korrigiere mich: s/man/ich/

TeXpert hat geschrieben:Kurz: ein Low-Level-Server *ist* nicht geeignet für eine große T3-Präsenz...
ACK
TeXpert hat geschrieben: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.
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!
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:
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.
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
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...
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.

Code: Alles auswählen

# to resolve all your problems, try this:
HOWTO='pack c5,41*2,sqrt 7056,unpack(c,H)-2,oct 115' && perl -le "print $HOWTO"
Ich beantworte keine Supportfragen per PM!

Benutzeravatar
panamajo
Guru
Guru
Beiträge: 2587
Registriert: 12. Feb 2005, 22:45

Beitrag von panamajo » 27. Apr 2006, 12:48

TeXpert hat geschrieben: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.
Bei so viel Sachlichkeit verzichte ich weitere Beiträge. :evil:

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast