Wie viel CRM passt auf eine 5,34€ Maschine?
“Aber braucht man dafür nicht erst einmal einen richtig großen Server?” - Das war eine Frage, die vor kurzem in einem meiner Kundengespräche gestellt wurde. Es ging um die Idee, als Piloten einzelne Prozesse aus der vom Kunden genutzten CRM-SaaS-Lösung in einer Eigenentwicklung abzubilden. Für den Kunden war das verständlicherweise eine gewichtige Frage: In einem Zeitalter, in dem der Ausbau von Datacentern und die rasant steigenden Kosten für Computing-Power tagtäglich in den Nachrichten sind, drängt sich natürlich die Frage nach den laufenden Kosten einer selbst betriebenen Lösung auf – und ob diese auf Dauer günstiger bleibt als der Zukauf einer SaaS-Lösung. Für mich Anlass genug, einmal zu untersuchen, was mit den günstigsten Maschinen am Markt bereits möglich ist.
Um ein Gefühl für die Antwort auf diese Frage zu bekommen, werfe ich heute einen Blick auf die kleinste virtuelle Maschine, die der Hosting-Anbieter Hetzner offeriert (und einen meiner persönlichen Lieblinge): die CX23 mit 2 vCPUs, 4 GB RAM und 40 GB SSD für (Stand heute) 5,34 € im Monat.
Etwas Kontext zu diesen Zahlen: Das MacBookPro4,1, aus der ersten Generation dieser Geräte aus dem Jahr 2008, glänzte mit 2 CPU-Kernen und 4 GB RAM. Der RaspberryPi 4B, ein vollwertiger Computer im Kreditkartenformat aus 2019, bringt 4 CPU-Kerne und bis zu 8 GB RAM mit.
Die CX23 also als schwachbrüstig zu beschreiben, wäre eine Untertreibung. Hat man für diesen Preis überhaupt eine Möglichkeit, irgendeine moderne, produktiv nutzbare Software zu betreiben?
Um diese Frage möglichst realitätsnah beantworten zu können, installiere ich auf einer solchen CX23 eine Instanz des quelloffenen CRMs NocoBase. In diesem Härtetest befinden sich anders, als man es in produktiven Umgebungen einrichten sollte, alle Softwarekomponenten auf dieser Maschine: Applikation, Datenbank, HTTP-Server… Gleichzeitig wurde nichts an der Standard-Konfiguration der Applikation verändert und es wurde kein Cache konfiguriert. Es handelt sich (absichtlich) um die wohl naivste Konfiguration, die nur irgend möglich ist.
Dies ist ein Versuchsaufbau!
Bei dem hier beschriebenen Systemaufbau handelt es sich um ein Experiment - Es geht um die Frage, was mit den kleinsten virtuellen Maschinen am Markt möglich ist. Keinesfalls sollte ein produktives System so betrieben werden!
Der erste Test
In meinem Test möchte ich eine möglichst realitätsnahe Auslastung des Systems simulieren. Für mich bedeutete das: Mehrere Nutzer müssen parallel mit dem System arbeiten – Daten werden gelesen, Einträge angelegt oder aktualisiert und durchsucht.
Im ersten Test-Szenario wird mit sehr einfachen Datensätzen gearbeitet: Das Objekt “Firma” hat lediglich einen Namen, eine Adresse und eine Telefonnummer. In diesem Test arbeitet eine immer größer werdende Anzahl an Nutzern mit diesen Datensätzen, wobei eine Hälfte der Nutzer neue Firmen anlegt, während die andere Hälfte durch die bestehenden Einträge navigiert.
Meine “Nutzer” sind allerdings Skripte, die diese beiden Szenarios in einer Schleife immer wieder abarbeiten, wobei die verwendeten Daten zufällig generiert werden. Für das System bedeutet dies noch mehr Stress: Anders als Menschen, die durch das System navigieren und Zeit dafür brauchen, die angezeigten Informationen zu verarbeiten, feuern die Test-Skripte pausenlos Anfragen ab. Ein absoluter Härtetest.
Für mehr technische Details zum Testaufbau hier klicken!
Die Parallelität der "Nutzer" wird in meinem Test durch Threads umgesetzt, sodass jeder "Nutzer" in einem eigenen Thread agiert. Mein für den Test verwendeter Rechner verfügt nur über 16 logische Kerne, was theoretisch zu Ungenauigkeiten in den Messungen führen könnte, wenn ein Request abgearbeitet ist, aber kein CPU-Kern bereitsteht, um die Antwort zu verarbeiten. Praktisch wird diese Verzögerung allerdings zu vernachlässigen sein, da dieser Test vor allem I/O-abhängig ist und die Threads die meiste Zeit nur auf Antworten warten werden.In meinem Test wird die Anzahl der parallelen “Nutzer” kontinuierlich vergrößert. Die Zeit für jede Anfrage wird gemessen und nach dem Typ der Anfrage gruppiert ausgewertet: “Lesen” bezeichnet die Anfragen, die ein spezifisches Objekt auslesen, “Suchen” beschreibt das Durchsuchen aller Objekte nach einem Muster, “Schreiben” beschreibt das Anlegen eines Objektes.
Bei 50 parallel ausgeführten Skripten, was deutlich mehr als 50 echten Menschen entsprechen würde, liegt die durchschnittliche Antwortzeit des Systems über alle Operationen hinweg bei circa 390 ms. Aber was bedeutet diese Zahl? Um besser zu visualisieren, wie sich eine solche Verzögerung anfühlt, habe ich den Test nochmals gestartet und habe währenddessen durch die Plattform navigiert:
Der in diesem Test verwendete Datensatz “Firma” ist natürlich deutlich einfacher aufgebaut als die meisten Datensätze aus echten Anwendungen. Das ist auch an der fehlenden Differenz in der Laufzeit der verschiedenen Operationen zu erkennen. Dies deutet darauf hin, dass nicht das Schreiben oder Lesen der Datensätze das Problem ist, sondern vielmehr das Abarbeiten der einzelnen Anfragen.
Der zweite Test
Daher wird der Test im zweiten Szenario mit einem anderen Datensatz wiederholt: Dieses Objekt enthält eine Referenz auf einhundert andere Datensätze, die Hälfte als One-To-Many und die andere Hälfte als Many-To-Many definiert. Um einen Datensatz anzulegen, werden zunächst diese 100 referenzierten Objekte erstellt, bevor der Hauptdatensatz angelegt wird. Wie im ersten Test zuvor wird der Hauptdatensatz parallel durchsucht und durch die Einträge navigiert.
Anders als im ersten Test ist nun ein deutlicher Unterschied in der Laufzeit der verschiedenen Operationen zu erkennen. Das Schreiben einer Testentität dauert um die 730 ms. Ein immer noch erträglicher Wert, wenn man davon ausgeht, dass in den meisten CRM-Installationen mehr Daten gelesen als geschrieben werden, oder dass die verwendeten Daten weniger komplex aufgebaut sind.
Fazit
Was lernen wir nun aus diesem Test? Für die allermeisten Anwendungen und Unternehmen wird für den Betrieb der eigenen Unternehmenssoftware keine große Hardware nötig sein, was zu niedrigen laufenden Kosten führt. Selbst bei einer Nutzerzahl im niedrigen dreistelligen Bereich wäre die in diesem Artikel getestete CX23 noch vollkommen ausreichend, um ein akzeptables Ansprechverhalten der Applikation sicherzustellen. Für den produktiven Betrieb sind andere Faktoren wichtiger: Redundanz, Backups und eine solide Updatestrategie.