Benötigte Bandbreite für eine Online-Plattform berechnen
Eine Online-Plattform, ein Webportal oder einen B2B Onlineshop ohne Besucher ist in der Regel nicht viel wert. Eine entsprechend hohe Besucherzahl ist in den meisten Fällen das Ziel. Doch: Besucher verursachen Traffic auf der Online-Plattform und beanspruchen somit entsprechend Ressourcen im Hosting. Als Softwarehersteller sind auch wir immer wieder mit der Frage konfrontiert, was die passende Dimensionierung für den Betrieb unserer Online-Plattformen und B2B E-Commerce Lösungen ist. Nebst den Anforderungen für Arbeitsspeicher (RAM), Prozessor (CPU) und Arbeitsplatz (Disk) ist ein wichtiger Faktor die Bandbreite. Wie kann man die notwendige Bandbreite berechen? In diesem Blogpost zeigen wir dir, wie wir von bambit da vorgehen.
Verschiedene Kategorien von Zugriffen
Eine Online-Plattform wird mittels Internettechnologien (HTTP-Calls) angesprochen. Akteure sind beispielsweise Benutzer mit Internet-Browsern, Mobile-Apps, IoT-Geräte (Internet of Things) oder andere Applikationen.
Als Erstes geht es also darum sich klar zu werden darüber, wer und was da mit der Online-Plattform kommuniziert. Grundsätzlich unterscheiden wir die Kommunikationsarten in zwei Kategorien:
- Kategorie 1: Besucher, welche die Online-Plattform mit einem Browser besuchen. (typischerweise Personen)
- Kategorie 2: Besucher, die nur an Daten der Online-Plattformen interessiert sind und via Schnittstellen kommunizieren. (typischerweise Mobile-Apps, IoT-Geräte, Applikationen usw.)
Je nach Kategorie gibt es unterschiedliche Herangehensweisen für die Berechnung der benötigten Bandbreite. Wie wir das machen, zeigen wir dir in den nächsten Abschnitten.
Kategorie 1: Bandbreite für Besucher mit Browser
In den meisten Fällen ist diese Kategorie heute noch die Mehrheit. Das Ziel ist hier den Besucher so zu begeistern, dass er bei einem Besuch mehrere Webseiten öffnet (Customer Journey). Mehr Seitenaufrufe bedeuten allerdings auch mehr Traffic und haben somit direkt Auswirkungen auf die benötigte Bandbreite.
Im Vorfeld zu bestimmen, wie viele Besucher auf einer neuen Online-Plattform im Durchschnitt agieren werden, ist nicht immer abschliessend möglich und gleicht manchmal einem Schuss ins Blaue.
Es bleibt in der Regel also nichts anders übrig als mal Annahmen zu treffen und jene nach dem Going-Live kritisch zu überwachen. Ist die Plattform einmal live geschaltet, können die notwendigen Werte sehr einfach gemessen, und die Infrastruktur bei Bedarf nachjustiert werden.
Für die Berechnung der Bandbreite sind folgende Annahmen zu bestimmen:
- Die durchschnittliche Pagesize in KB. Wenn der Wert unbekannt ist, können Tools wie zum Beispiel Pingdom helfen.
- Anzahl erwartete Seiten, die ein Benutzer bei einem Besuch im Schnitt öffnet.
- Erwartete Anzahl Besucher pro Sekunde, Minute, Stunde etc..
Nachfolgendes Beispiel verdeutlicht die Berechnung:
| Durchschnittliche PageSize | 500 KB |
| Durchschnittliche Anzahl Seiten pro Besuch | 4 |
| Anzahl Besucher pro Minute | 2 |
| Anzahl Besucher pro Stunde | 120 |
Basierend auf den Informationen kann nun die benötigte Bandbreite berechnet werden:
| Einheit | Grösse | Bemerkungen |
|---|---|---|
| Pro Minute | 4 MB | (4 * 500KB) * 2 |
| Pro Stunde | 240 MB | |
| usw.. | usw.. |
Kategorie 2: Bandbreite für Datenschnittstellen
Besucher, die nur an Daten einer Online-Plattform interessiert sind, interagieren meist mit Web API's (siehe auch Blogpost Wie-Web-APIs-helfen-Wertschoepfungsketten-zu-veraendern) und bekommen dementsprechend JSON oder XML retourniert. Solche Besucher sind dann nicht Personen, sondern Dinge wie Applikationen, Mobile-Apps oder IoT-Devices.
Zur Veranschaulichung machen wir folgendes Beispiel: Eine Online-Plattform hat einen REST-Endpoint, um mit Personen-Entitäten zu interagieren. In unserem Beispiel stehen folgende REST-Endpoints zur Verfügung:
| Endpoint | HTTP Verb | Beschreibung |
|---|---|---|
| /api/persons | GET | Retourniert alle Personen als Liste |
| /api/persons/{id} | GET | Retourniert eine Person anhand deren ID |
| /api/persons | POST | Erstellt eine neue Person. |
Eine Person-Entität wird dabei durch das folgende JSON-Format repräsentiert.
{
"id": 5,
"name": "Muster",
"vorname": "Jasmine",
"adresse": "Musterstrasse",
"plz": "1234",
"ort": "musterhausen",
"telefonnummer": "+41 11 111 11 11",
"geschlecht": "weiblich",
"geburtsdatum": "2001-02-03"
}Um die Datengrösse einer Person-Entität zu ermitteln, bietet es sich an eine Beispiel-Response in einem Texteditor zu erstellen und die Datei als .txt-Datei auf die Harddisk zu speichern. Mittels dem Eigenschaftsdialog unter Windows kann anschliessend die Dateigrösse ermittelt werden. (in unserem Fall 230 Bytes).
Diese Grösse von 230 Bytes nehmen wir nun als Ausgangslage für die Grösse einer Response vom REST-Endpoint /api/persons/{id}. (Hinweis: Die Response ist in Tat und Warheit etwas kleiner. Der Dateityp .txt benötigt auch noch ein paar Bytes. Für die Bandbreitenberechnung kann dies aber ignorriert werden).
Als Nächstes ist interessant zu definieren, wie viele Personen-Entitäten die Online-Plattform insgesamt beherbergt und wieviele Personen bei dem Aufruf von dem REST-Endpoint /api/persons maximal retourniert werden. In diesem Beispiel gehen wir davon aus, dass der GET-Aufruf auf /api/persons maximal 20 Personen retourniert. Dadurch ergeben sich folgende Werte:
| Endpoint | Grösse | Bemerkung |
|---|---|---|
| /api/persons/{id} | 500 Bytes | Entspricht der Filegrösse von 230 Byte. Zusätzlich haben wir den Wert noch etwas erhöht wegen dem HTTP-Overhead und allfällig geplantem Datenwachstum. |
| /api/persons | 10 KB | Es werden maximal 20 Personen-Entitäten retourniert. Eine Personen-Entität haben wir auf 500 Bytes festgelegt. Somit ist der Wert 20 * 500 Byte = 10'000 Byte = 10 KB |
Für die Bestimmung der Bandbreite müssen wir uns nun noch Prognosen machen wie oft die REST-Endpoints pro Sekunde aufgerufen werden.
| Endpoint | Anzahl Aufrufe pro Sekunde |
|---|---|
| /api/persons/{id} | 3 |
| /api/persons | 1 |
Basierend auf den Informationen kann nun die benötigte Bandbreite berechnet werden:
| Einheit | Grösse | Bemerkungen |
|---|---|---|
| Pro Sekunde | 11.5 KB | (3 x 500 Byte) + (1 x 10 KB) |
| Pro Minute | 690 KB | |
| Pro Stunde | 41.4 MB | |
| Pro Tag | 173 MB |
Bemerkung zu der Bandbreite pro Tag: Es wird als Beispiel davon ausgegangen, dass der Traffic primär in den Stunden zwischen 06:00 Uhr und 23:00 Uhr stattfinden wird. Für die Prognose werden nur diese Stunden berücksichtigt. (17 Stunden). Die Schwankungen zwischen 06:00 Uhr und 23:00 Uhr sollten den zusätzlichen Traffic in den Randzeiten mit abdecken.
Fazit
Vor Going-Live die benötigte Bandbreite zu bestimmen ist nicht immer einfach. Mittels der passenden Herangehensweise kann aber bereits im Vorfeld eine Eingrenzung erzielt werden. Wichtig ist dabei, dass die Arten von Traffic unterschiedlich betrachtet werden. Besucher mit einem Internetbrowser verursachen eine andere Form von Traffic und beanspruchen damit die Bandbreite auf eine andere Art und Weise, als Konsumenten, die ein Web API Endpoint aufrufen.
Auch bei einer Vorgängigen Berechnung empfiehlt es sich, den Traffic nach Going-Live konstant zu überwachen und entsprechend Justierungen vorzunehmen. Typischerweise wachsen die Anforderungen an die Bandbreite mit der Lebensdauer der Online-Plattform mit.