Vergleich LiveServer – Publishing-/Staging-Server

Definition

Durch die Aufteilung in Publishing-/Staging-Server ergeben sich zahlreiche Möglichkeiten, wie auch etliche Problematiken. Ein Vorteil auf Seiten des Live-Servers, ist jedoch nicht automatisch ein Nachteil bei einem Publishing-/Staging-Server-System ist. Oftmals lassen sich die vermeintlichen Nachteile durch entsprechende Workarounds schnell und einfach beheben.

Sicherheit

Eines der treffendsten Argumente für die Trennung der Systeme ist die damit verbundene Erhöhung der Sicherheit. Bei einem Publishing-/Staging-Server-System kann der Publishing-Server durch die Separierung bereits auf Netzwerkebene getrennt werden. Es wäre hierbei denkbar den Publishing-Server hinter einer eigenen Firewall aufzustellen und/oder diesen nur über das Intranet erreichbar zu machen. Dadurch wird die Gefahr eines Angriffs von außen (also aus dem Internet) drastisch reduziert. Ein Live-Server hingegen kann diese Aufteilung aufgrund der Systemarchitektur nicht leisten.

Skalierbarkeit

Die Skalierbarkeit des Systems bezieht sich auf die Frage, wie einfach sich das System erweitern lässt, falls eine Überlast auftritt. Bei einem Live-Server muss bei Überlast das gesamte System erweitert werden. Wohingegen bei einem Publishing-/Staging-Server durch die klare Strukturierung einzelne Komponenten gezielt ausgebaut bzw. angepasst werden können.

Performance

Unter Performance versteht man die Reaktionszeit des Servers auf Anfrage der Benutzer und Redakteure des Systems. Die Antwortzeiten sind dabei abhängig von der Prozessorleistung, des Taktfrequenz und Größe des Hauptspeichers, der Zugriffzeiten auf Datenbanken und/oder des Dateisystems, der Durchsatzleistung, der Netzwerkanbindung uvm. Im Falle eines Publishing-/Staging-Server kann die Hardware entsprechend den Anforderungen gezielt optimiert werden. Es wäre beispielsweise denkbar, auf Seiten des Staging-Servers eine hoch performante Festplatte mit erweitertem Cache einzusetzen, um eine schnellen Zugriff auf die statischen Inhalte im Dateisystem zu gewährleisten, und der Publishing-Server erhält einen vergleichsweise schnellen Prozessor für einen raschen Export der Inhalte. Im Gegensatz dazu sind bei einem Live-Server auch die Redakteure bei hohen Aufkommen von Benutzeranfragen von einer schlechten Reaktionszeit des Systems betroffen. Hier muss dann das gesamte System erweitert werden.

Ausfallsicherheit

Durch eine Trennung in Publishing-/Staging-Server, kann auch die Ausfallsicherheit erhöht werden, da im Falle eines Defektes seitens des Publishing-Servers, der Staging-Server immer noch erreichbar ist. Sollte der Staging-Server ausfallen, können einerseits die Redakteure davon unbeirrt weiterarbeiten und andererseits kann man die Inhalte schnell und einfach auf ein anderes System exportieren. Wenn jedoch ein Live-Server ausfällt, ist das System für keine Nutzergruppe erreichbar und es muss zuerst der Fehler analysiert, gefunden und behoben werden, was meist geraume Zeit in Anspruch nimmt.

Wartung

Auch bei der Wartung des Systems ist bei einem Live-Server die Webseite sowohl für die Benutzer, als auch die Redakteure nicht mehr erreichbar, wie es immer wieder bei ebay.de freitags der Fall ist. Im Vergleich dazu ist der Ablauf bei einem Publishing-/Staging-Server durchaus moderat. Wenn der Staging-Server gewartet wird, so kann auch hier auf gesonderte Hardware exportiert werden, welche den zeitlich begrenzten „Ausfall“ überbrückt. Wartungsarbeiten am Publishing-Server können meist nachts, wenn die Redakteure keine Inhalte bearbeiten, durchgeführt werden.

Suchmaschinen

Suchmaschinen wie Google und Yahoo! erfassen dynamische Inhalte nur begrenzt. Im Falle von Google werden datenbankgenerierte Web-Inhalte laut Google-Hilfe indexiert, es wird jedoch darauf hingewiesen, das der Crawler dabei Probleme hat und die Seiten dann ignoriert werden. Somit hat das Publishing-/Staging-Server-System, bei dem alle Seiten statisch hinterlegt sind, hier einen klaren Vorteil gegenüber dem Live-Server, welcher sämtlichen Inhalt dynamisch erzeugt. Dieser Nachteil kann jedoch durch entsprechende Workarounds, wie sie XIST4C nutzt, umgangen werden. Dabei wird die Seite nicht mit dynamischen Parametern in der URL angesprochen, sondern die URL enthält die eindeutige ID, anhand welcher die Seite im System gefunden wird. Daneben werden die XIST4C-Seiten mit der Dateiendung .htm versehen, um für die Suchmaschinen den Anschein zu erwecken, dass die Inhalte statisch sind.

Quellen

• Krüger, Jörg; Kopp, Matthias (2002): Web Content managen
• Zschau, Oliver et. al. (2001): Web Content Management
• Ebay-System-News
• Indexierung von dynamischen Inhalten bei Google
• Suchmaschinenfreundliches Content Management System XIST4C

Siehe auch

• Live-Server-Architektur
• Publishing-/Staging-Server-Architektur