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.
Hardware
Bei der Hardware tauchen die vermeintlich ersten Nachteile einer Publishing-/Staging-Server-Architektur auf, da hier zwei separate Systeme gekauft und administriert werden müssen. Bei einem Live-Server bedeutet dies nur den halben Aufwand. Gehen wir jedoch von einem System mit vielen Redakteuren aus, welches in einem bereits vorhanden Rechenzentrum betrieben wird, so ist der Kostenfaktor für zusätzliche Hardware und bereits verfügbares Personal vernachlässigbar.
Suche
Mittlerweile ist es für jeden vernünftigen Internetauftritt ein Muss, eine Suche über die verfügbaren Inhalte anzubieten. Die Suche in einem Live-Server kann meist ohne weitere Anstrengungen mit Hilfe der Suchmechanismen der Datenbank, in welcher die Inhalte hinterlegt sind, umgesetzt werden. Da aber ein Staging-Server per Definition keine direkte Verbindung zum Content Repository des Publishing-Servers haben soll, muss hier eine gesonderte Lösung der Suche eingesetzt werden. Ein Ansatz ist, den Index über die Suchinhalte beim Export zu erstellen und diesen auf dem Staging-Server mit einem eigenständigen Modul anzusprechen.
Personalisierung
Auch die Personalisierung kann mit leichtem Vorteil für das Live-Server-System gewertet werden. Durch die oftmals schon integrierte Benutzerverwaltung in das System, lässt sich diese Funktionalität einfach und schnell umsetzen. Bei einer Publishing-/Staging-Server-Architektur muss dies wie die Suche gesondert behandelt werden. Meist wird eine auf dem Staging-Server eigenständige Benutzerverwaltung realisiert. Dieser Workaround beinhaltet dann aber auch eine zusätzliche Datenhaltung der Benutzereinstellungen (z.B. in einer Datenbank) und damit auch eine Erweiterung der Funktionalität des „einfachen“ Webservers.
Aktualität
Der entscheidende Grund für ein Live-Server ist häufig die Aktualität der Daten. Durch den direkten Zugriff auf die eingepflegten Inhalte ist eine Veröffentlichung der Informationen in Echzeit möglich. Vor allem bei Warenwirtschaftssystemen im E-Commerce-Bereich, wie auch bei Online-Zeitungen ist diese Eigenschaft unabdinglich. Man könnte dies auch auf einem Publishing-/Staging-Server-System nachbilden, indem man ununterbrochen einen Export der neuen und/oder aktualisierten Inhalte durchführt. Da dies jedoch die Performance des Publishing-Servers dauerhaft reduziert und beispielsweise bei der Suche auch der Index immerzu aktualisiert bzw. neu erzeugt werden muss, kann dies nicht als angebrachter Workaround gewertet werden.
Auflistung der Vor- und Nachteile
| Live-Server | Publishing-/Staging-Server | |
| Sicherheit | – | + |
| Skalierbarkeit | – | + |
| Performance | – | + |
| Ausfallsicherheit | – | + |
| Wartung | – | + |
| Suchmaschinen | o | + |
| Hardware | + | o |
| Suche | + | o |
| Personalisierung | + | o |
| Aktualität | + | – |
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
