Die optimale Anbindung eines RedDot CMS Servers für Webprojekte

Der Seitenaufbau dauert rund 15 Sekunden, wenn es gut läuft 5 - und das ist noch immer zu viel. In den seltensten Fällen ist die Ursache hierfür ein schwaches System, denn dies ist noch am schnellsten aufgerüstet. Ein kleinerer RedDot CMS Server, der auf Windows 2003 läuft und auf eine externe MSSQL Datenbank zugreift kommt “schon” mit einer Dual-Core Lösung um die 2GHz und 4Gigabyte Arbeitsspeicher aus.

Was, wenn das System immernoch langsam läuft? Und was, wenn dies intern nicht so schnell bemerkt wird, weil der RedDot CMS Server im firmeneigenen Netzwerk steht und zumindest die internen Redakteure damit eine akzeptable Zugriffszeit haben? Diese Lösung ist optimal für Intranetlösungen und auch für midsize-solutions mittelgroße Lösungen, bei denen die Mehrzahl der Zugriffe durch firmeninterne Redakteure stattfindet.

Problematisch wird das ganze dann, wenn das Unternehmen die RedDot Migration als international genutztes Extranet nutzt und alle Zugriffe über die Firmenstandleitung laufen(und diese eventuell schon in die Tage gekommen ist). Die Zeit für den Seitenaufbau steigt enorm, der RedDot Redakteur muss warten und die Akzeptanz gegenüber dem Redaktionssystem sinkt allmählich, obwohl das System selbst durchaus schnell funktioniert. Der Flaschenhals ist das Firmennetz, welches neben den RedDot-Anfragen die E-Mail Kommunikation, sowie extern verbundene Exchange-Clients und Anderes bedienen muss, und natürlich dazu den gesamten Internetverkehr regelt. Da kann es zu Stoßzeiten durchaus zu längerem Warten vor dem Browser kommen.

Bei einem Redakteur ist dies schon schwer zu vertreten, da dieser meist tagtäglich das RedDot System bedienen muss und dies am besten schnell und kosteneffizient. Wenn nun allerdings dasselbe einem RedDot Entwickler passiert, dass eine Serveranfrage möglicherweise den festgelegten TimeOut-Rahmen sprengt und beim Abspeichern eines neuen oder stark modifizierten RedDot Templates mit vielen neuen RedDot Elementen der Browser sich “aufzuhängen” scheint, dann bedeutet dies, dass ettliche Schritte im RedDot Projekt für dieses Template wiederholt werden müssen. Und das ist spätestens beim dritten fehlerhaften Abspeichern des Templates nicht mehr amüsant.

Wo sollte ein RedDot CMS Server also stehen(falls es keinen Entwicklungsserver gibt versteht sich..)? Reicht es, den Server in die DMZ zu stellen und ihm über die Standleitung eine eigene fixe Bandbreite zur Verfügung zu stellen? Sollte der RedDot Server vielleicht einfach eine eigene DSL-Leitung bekommen? Oder ist es am besten, wenn das RedDot System komplett in einem Rechenzentrum steht und dort eine bestmögliche Anbindung an das weltweite Internet hat?

Die Vor- und Nachteile dieser Möglichkeiten lassen sich auflisten (und wenn jemandem etwas einfällt, dass ich hier vergesse, dann lassen Sie sich sogar ergänzen!)

Platzierung: Normales Rechenzentrum
Vorteile: Hohe Verfügbarkeit bei entsprechendem Backbone, gute Anbindung für Unternehmen mit vielen internationalen Zugriffen auf das CMS, klare Abgrenzung von der firmeninternen Infrastruktur
Nachteile: Hoster spielen gerne ohne Vorwarnung Windows Servicepacks ein, was zu Fehlern führen kann. Eineventueller Abgleich mitgrößeren Datenmengen aus dem Firmennetz braucht länger und sollte unbedingt getunnelt werden. 24/7 Hand-On Support ist teurer und RedDot-Administratoren müssen ggf. vor Ort sein bei Updates (was sich aber in der Regel auch Remote lösen lässt)

Platzierung: Firmenintranet
Vorteile:
Hohe Verfügbarkeit für Redakteure, die eine gute Anbindung in das Firmennetz haben, meist nur interne RedDot Benutzer. Klare Abtrennung der Stagingumgebung vom Webserver. Datenbankanbindungen für firmenintern erstellte Daten sind leichter zu realisieren(Produktkataloge, etc.). Updates & Serverwartung liegen bei der Firmen-IT.
Nachteile: Die Erreichbarkeit des RedDot CMS ist abhängig von der Verbindung und Nutzung des gesamten Intranets(E-Mails, Webbrowsing,Datenabgleich über getunnelte Verbindungen zu Niederlassungen, etc.). Externe Redakteure und RedDot Administratoren haben oft eine langsame Verbindung - bei Tunnelverwendung wie z.B. mit VPN kann es bei einer schlechten Verbindung zu Timeouts kommen.

Platzierung: Firmenintranet (gekapselt)
Vorteile:
Hohe Verfügbarkeit für RedDot Administratoren und Redakteure, die eine gute Anbindung in das Firmennetz haben. Für interne Benutzer durch durch eine eigene Netzwerkkarte ins Firmennetz, für externe Benutzer und RedDot Dienstleister oder Agenturen mit einer eigenen DSL-Leitung ins Internet(am besten mit einem weiteren Schutz ausser dem RedDot CMS Login). Bessere Anbdingung für Datenbankabgleich mit internen Datenquellen. Guter Mix zur Verfügbarkeit für interne und externe Zugriffe ohne Abhängigkeit vom restlichen Datenverkehr der Firma.
Nachteile: Eventuelles Sicherheitsrisiko für die Firmen-IT, da die Firewall hier umgangen werden kann. Abhängigkeit für externe Zugriffe von der DSL-Verbindung.

Letzendlich entscheided die Anforderung an das System und die Infrastruktur darüber, wie ein mittelständisches Unternehmen eine solche Lösung zu meistern versteht. Ein RedDot Entwickler wünscht sich jedenfalls einen sicheren TemplateEditor, der keine Timeouts mehr ausgibt, Templates sauber abspeichert und der einem das Leben als RedDot CMS Admin einfach etwas leichter macht. Anregungen hierzu sind natürlich jederzeit gern gesehen.

1 Star2 Stars3 Stars4 Stars5 Stars (4 votes, average: 4.25 out of 5)
Loading ... Loading ...

Kommentarfunktion ist deaktiviert