Herausforderung Problem-Zonen Movable Type - ein Feedback - einfach persoenlich Weblog

Herausforderung Problem-Zonen Movable Type - ein Feedback

06.07.2006 | Blogger, Blogging Tipps, Movabletype, Weblog - Talk | 6 Kommentare | Print

Jedes Weblog-System hat Schwachstellen. Problem-Zonen von Movable Type kann man aber auf unterschiedlichste Art und Weise zu Leibe gehen. Einige Ansätze beschreibt ein persönliches Feedback für Robert.

Kein Weblog-System hat nur Nachteile. Angestachelt durch Leser habe ich in die Vorzüge von Movable Type einmal zusammengestellt. Wer über die Vorteile eines Systems schreibt, wird prompt auch nach den Nachteilen gefragt.

Dabei macht es sich deutlich, dass neben wirklichen Nachteilen auch eine Menge Vermutungen oder ältere Erfahrungen heute noch das Meinungsbild bestimmen. Danke Robert, dass Du mir den Ball einfach zuspielst, gern will ich versuchen, Deine Fragen etwas zu beantworten.

Gern beziehe ich mich nach dem Beta-Test nun hierbei bereits auf die MT Version 3.3, die in der Final Release Version 3.3b F.R.C. ja vorliegt.

Aktueller geht nimmer!

Problem-Zone 1 - Zeitraubender Aufbau von HTML-Dateien

Die Dauer zum Abspeichern eines neuen Artikels/Kommentars ging mit zunehmender Artikelmenge dramatisch hoch. Das bezieht sich auf die damalige Version 2.66. Was Six Apart (die Herstellerfirma von MT) mittlerweile dagegen getan hat? Keine Ahnung. Ebenso ging es den Usern auf die Nerven, ihre Kommentare zu speichern. Auch das dauerte immer länger.
basicthinking

Wenn eine Software wie Movable Type statische HTML-Dateien generiert, dann braucht dies logischerweise einfach ein wenig Zeit. Ein dynamisches System erfordert dies nicht, da jede Website in Echtzeit bei jedem Abruf neu zusammengebaut wird, besser gesagt werden muss. Movable Type ruft dabei nur (je nach Konfiguration) eine HTML-Datei ab. Das macht schon mal einen Unterschied.

MT 3.3 ist wesentlich schneller beim Generieren der Dateien als MT 2.66, auch noch einmal schneller und effizienter als MT 3.2.

• Redundate Module werden nicht mehr blind kompiliert, sondern gecacht.
• Leere Template-Module werden übersprungen.
• Der Rebuild-Prozess ist überarbeitet, hat mehr Power & Speed.

Aber auch MT 3.3 braucht etwas Zeit.
Entscheidend sind besonders zwei Faktoren dafür:

1. Wieviel Dateien müssen auf einmal kompiliert werden?
2. Wieviel Templates, Module und Datensätze müssen bearbeitet werden?

Nicht immer müssen alle Dateien neu aufgebaut werden, insbesondere nicht, wenn nur ein Beitrag veröffentlicht werden soll. Dann erstellt MT normalerweise nur:

• der Beitrag,
• das Kategorie-Archiv,
• das Datums-Archiv und
• alle Index-Templates

neu. Alle sich selten ändernden Dateien können aus diesem Prozess ausgeschlossen werden. Man kann Ressourcen schonen. Weitere Zeit und Kraft gewinnt man unter anderem durch:

1. Ausschluss von selten erstellten Dateien aus dem Rebuild,
2. Gemischter Einsatz von dynamischen und statischen Templates,
3. Ressourcenarmes, modulares Template-Design,
4. Vermeidung von Last-intensiven Template-Schleifen,
5. Abschaltung unnötiger Plugins,
6. Leistungsfähiges Hosting,
7. Effiziente MT-Einstellungen & Konfiguration,
8. Geringe Zahl von Weblog-Templates.

Man baut nur auf, was man wirklich braucht. Ein intelligentes Projekt-Design ist bei großen und individuellen MT-Weblogs mehr denn je erforderlich.

Problem-Zone 2 - Lange Kommentar-Speicherung

Ebenso ging es den Usern auf die Nerven, ihre Kommentare zu speichern. Auch das dauerte immer länger.
basicthinking

Eine lange Kommentarspeicherung hängt ursächlich mit Rebuild-Prozessen zusammen, die beim Speichern des Kommentares im Hintergrund die statischen Seiten neu aufbauen. Wer Problem-Zone 1 in den Griff bekommt, hat automatisch hier ebenso seine Vorteile und Verbesserungen. Wer viele Plugins für allerlei kleine Dinge braucht, bezahlt den Aufwand einfach an dieser Stelle. Deshalb plädiere ich mittlerweile für Weniger ist mehr!

Problem-Zone 3 - Kleine Änderungen bringen großen Aufwand

Und wenn Du erst einmal 2.000 oder 3.000 Artikel geschrieben hattest und dann am Template etwas ändern wolltest… gute Nacht! Damals hatte MT jeden Artikel als HTML-File abgelegt. So musste die MT Engine alle 2.000 Files durchnudeln, um eine winzige Änderung an irgendeiner Stelle des Templates durchzudrücken. Da bist Du schier wahnsinnig geworden!
basicthinking

First breack all the Rules! Auch hier gilt der Grundsatz. Ein intelligent geplantes Weblog-Design nutzt Module, PHP-Includes oder SSI und erzeugt nur die Teile der HTML-Seiten, die jeweils geändert werden müssen. Gemischter dynamischer Betrieb der Seiten verbessert die Effektivität obendrein.

Dann klappt’s auch wieder mit dem Nachbarn. : ))

Problem-Zone 4 - Große Kategorie-Archive

Die Archivdateien (Kategorien und Monatsarchiv) wurden immer dicker. Eine Monatsarchivdatei war so an die 200-250 KB groß. Die muss erstmal geladen werden. Und die Zugriffe auf die alten Archive waren nicht gerade gering. Viel schlimmer: Die Kategorie-Files wurden immer dicker. Denn auch hier legt MT ein HTML-File je Kategorie an. So war zum Schluss die Kategorie Entspannung mal locker 400 KB groß! Projiziert man das Wachstum weiter, wurde einem Angst und Bange :-)
basicthinking

Das Zauberwort heißt auch hier: intelligentes Template-Design. Dynamische Kategorie-Archive in Verbindung mit Paginierung (statisch oder dynamisch) sind effektive Maßnahmen zur Vorbeugung.

Wer zudem viel Content in einem Blog veröffentlicht, sollte ernsthaft darüber nachdenken, wie er mit den beiden Feldern EntryBody (Teaser/Anreizer) und EntryMore (Erweiterter Text) umgeht. Je textlastiger die Kategorie-Seiten, umso größer, behäbiger und langsamer werden die Seiten insgesamt und umgekehrt.

Denken wir also ab und an auch mal an andere Lösungswege. Nicht immer muss es ja der Hersteller sein, vielleicht haben wir einfach nur das System überfordert und betreiben es nahe den technisch sinnvollen Grenzen. Meist ergeben sich beim Nachdenken auch noch andere Handlungsalternativen. Wenn all das nicht mehr reichen sollte, kann man dann ja immer noch die Software wechseln.

Fazit - Know-how der Details macht den Unterschied

MT ist ein System mit unglaublichen Potenzialen. Nachteile werden aber immer einige bleiben. Dennoch kann man viele Nachteile geeignet umschiffen und vermeiden. Viele Kniffe und das tiefere Verständnis für das System stellen sich aber meist erst nach längerer und intensiver Beschäftigung mit der Materie ein.

Nicht jeder mag dafür Zeit und Nerven haben. Aber man kann ja einfach auch jemand fragen, der sich mit dem Thema auskennt. Meist ist der Einkauf von Know-how preiswerter als alle zeitraubende Bastelei im eigenen Keller. :)

Ein schnellerer Erfolg gerade für professionellen Einsatz ist oftmals der Lohn.

PS: Oder würdet Ihr selbst ein Fahrrad konstruieren und bauen,
wenn Ihr einfach nur einmal damit fahren wollt?

War der Artikel für Euch wertvoll? Wollt Ihr Euch den Beitrag als Bookmark merken?
Einfach RSS-Feed abonnieren oder das Lesezeichen mit anderen Menschen teilen:

• RSS-Feed abonnieren
• Bookmark bei del.icio.us
•