Die richtigen Messdaten machen gutes Hosting einfacher!
Eine gute Ausschreibung fürs Serverhosting setzt Wissen über die Leistungsanforderungen einer Internetanwendung voraus. Dazu sollten Sie die Zusammenhänge zwischen Serverart, Speicherbedarf, CPU und RAM-Kapazitäten, Festplattensystem, Zugriffszahlen und anderen Daten kennen. Bei einem „Neubau“ helfen die Schätzungen oder Erfahrungswerte der betreuenden Agentur. Aber wenn ein Shop oder eine Website auf ein neues Serversystem zu einem anderen Anbieter umziehen soll, dann können Sie auf dem bestehenden System alle notwendigen Messdaten sammeln und allen an der Ausschreibung Beteiligten zur Verfügung stellen. Und so geht’s:
Verfahren zur Messdaten-Sammlung für Ihre Ausschreibung
Wenn Sie eine bestehende Website oder einen Online-Shop erneuern wollen, dann stehen Ihnen tatsächlich nützliche Erfahrungswerte aus dem bestehenden Betrieb zur Verfügung. Diese Daten braucht der Anbieter als Berechnungsgrundlage für ein solides Angebot.
Zugriffszahlen sind Standard in der Ausschreibung
Eine erste wichtige Quelle sollte Ihnen vertraut sein: die Besuchsstatistiken. Fragen Sie in Ihrer Agentur oder Marketingabteilung nach. Diese kennen die Zugriffszahlen auf Ihre Websites dank Website Analyse System. Idealer Weise sind diese Daten dort sogar über größere Zeiträume archiviert. Dem Angebotsersteller geben sie erste wichtige Hinweise, welche Performance der neue Server grundsätzlich aufbringen muss.
Technische Serverbetriebsdaten mit LINUX-Befehl ermitteln
Ein bisschen tiefer können Sie Informationen schürfen, wenn Ihr alter Server auf Linux-Basis läuft. Denn dieses Betriebssystem liefert mit dem Befehl „top“ ganz grundlegende Daten für die CPU- und RAM-Last. Das ist zwar etwas „händisch“ und muss der Admin erledigen, aber es ist besser als nichts. Voraussetzung ist hier, dass Ihre Anwendung auf einem eigenen, gerne auch virtualisierten Server läuft, anstatt auf einem „Web-Package“. Dann kann ein Fachkundiger an die Analyse des Ist-Zustandes gehen und sogar den Speicherbedarf recht genau einschätzen.
Aber natürlich gibt es hier auch externe Lösungen, die Ihnen wichtige Daten für Ihre Ausschreibung liefern. Wir stellen Ihnen hier ein Methode vor, die wir bei einigen Umzügen als Planungshilfe und Erfolgskontrolle erfolgreich eingesetzt haben. Der vermeintliche Geheimtipp heißt: externes, qualifiziertes Monitoring.
Leistungsdaten über ein externes Monitoring sammeln
Bei der BB-ONE.net greifen wir für unsere Kunden auf Daten aus dem qualifizerten Monitoring zurück. Wenn der Kunde zu uns wechseln will, dann installieren wir auf dem laufenden Server den SNMP-Dienst. Danach monitoren wir über einen Zeitraum von vier Wochen die wichtigsten Betriebsparameter wie Speichernutzung, RAM-Nutzung, CPU-Nutzung, Bandbreiten etc. Dies wird in unserem Monitoring-System gespeichert und zeigt somit die Ressourcen-Nutzung über einen längeren Zeitraum auf. Dabei werden natürlich auch Engpässe auf dem bestehenden System gut sichtbar. Aber es hilft uns auch bei der Planung der zukünftigen Ressourcen.
Zusätzlich lesen wir entweder den vorhandenen Website-Analyzer aus. Oder wir setzen temporär unseren Matomo-Server auf, um die echten Zugriffszahlen sowie einige weitere für den Relaunch wichtige Informationen zu ermitteln. Bereits nach Ablauf von ca. vier Wochen können wir ziemlich genau erkennen, welche Leistungsdaten wir unbedingt berücksichtigen und wo wir das Angebot großzügiger anlegen müssen. Oder anders ausgedrückt: Wir wissen dann, wie „anstrengend“ die WebSite ist und welche Leistungen tatsächlich gebraucht werden.
Falls dann zusätzliche Software wie z. B. eine interne Suchmaschine auf Java-Basis hinzukommen soll, können wir auch hier recht genau sagen, welche Ressourcen dafür notwendig sein werden.
Die Standard Leistungsdaten
Hier ist beispielhaft zu sehen, wie wir aus einem temporären Monitoring recht exakt auf die erforderlichen Leistungsdaten schliessen können. Dies ist eine Übersicht über die Leistungsdaten, die wir während eines Monitorings erheben. Dazu gehören:
- Speicherplatznutzung für zwei getrennte Partitionen
- Auslastung des Arbeitsspeichers sowie des Auslagerungs-Speichers
- Anzahl der offenen Softwareprozesse
- verschiedene Messungen zur Prozessor-Last
Diese Leistungsdaten werden während eines Zeitraumes von wenigstens vier Wochen aufgenommen. Je länger dieser Messzeitraum ist, um so genauer kennen wir das Verhalten des Servers und können auf eine Ausschreibung ein angemessenes Angebot abliefern. So geschehen beim folgenden Beispiel eines Kunden, dessen Shopserver regelmäßig Aussetzer hatte. Und niemand wusste so genau, warum. Deshalb machten wir uns vorher auf die Spurensuche.
Auf der Suche nach „Spitzenleistungen“
Nach den Standardmessungen suchten wir nach Spitzen und „Pausen“. Wenn es dabei zu erkennbaren Mustern kommen würde (z.B. extreme Spitzen jeden Abend zwischen 20:00 und 21:00), dann deutete dies auf zeitlich begrenzte Probleme hin.
Kurzzeitmessung der CPU-Last
In dem gezeigten Beispiel sehen Sie zwei Spitzen in der CPU-Nutzung innerhalb von 2 Tagen. Sie weisen auf eindeutige und spezifizierbare Probleme hin, die auf dem bestehenden System im Bereich der Server- und Dienste-Konfiguration zu finden waren. Da die Spitzen niemals über 35% der Ressource CPU gehen, handelte es sich in diesem Beispiel also nicht um ein klassisches Ressourcen-Problem. Die Cache-Kofiguration des Shop-Systemes war auf dem alten Server einfach fehlerhaft.
Langzeitmessung der CPU-Last
Bei einer Langzeitbeobachtung sahen wir zunächst regelmässige Spitzen in der CPU-Auslastung, danach war längere Zeit „Ruhe“. Nach zwei Wochen gab es dann andere Lastmuster, sogar mit einem längeren Totalausfall. Das konnten wir dank dieser Messdaten in unserem Angebot berücksichtigen. Letztlich hatte der Kunde die Wahl zwischen deutlich mehr CPU-Ressourcen, um die instabil laufende Anwendung zu stützen oder die Anwendung strukturell zu verbessern. Logischerweise wäre die zweite Methode die bessere aber teurere gewesen. Deshalb boten wir an, zweigleisig zu fahren.
Langzeitmessung der Arbeitsspeicherauslastung
Auch hier konnten wir ein monatlich wiederkehrendes Phänomen beobachten. Ziemlich genau alle vier Wochen musste ein Dienst resettet werden. Danach gab es wieder einen stabilen Betrieb für drei Wochen. Die Messung der Arbeitsspeicher-Nutzung wies letztlich auf zu wenig Arbeitsspeicher für einen monatlichen Datenbank-Dump hin.