Administratoren verwenden oft Open-Source-Benchmarking-Tools wie "IOZone" und "bonnie++". Datenbanksysteme wie Redis und MySQL verfügen zudem über eigene Messwerkzeuge. Das übliche Problem dieser Werkzeuge ist jedoch, dass sie mit vorgegebenen, künstlichen I/O-Mustern arbeiten. Obwohl diese den sequenziellen und randomisierten Datenzugriff testen, entsprechen die Muster nicht dem, was auf Produktionssystemen vorzufinden ist. Eine andere Möglichkeit besteht darin, eine separate Lasttestumgebung zu verwenden, in der eine Produktionsumgebung mit allen Abhängigkeiten simuliert wird. Eine Umgebung, die aus vielen Microservices besteht, ist jedoch sehr komplex. Microservices müssen zudem normalerweise von verschiedenen Teams verwaltet werden, was den Koordinationsaufwand erhöht.
Eine weitere Herausforderung besteht darin, die Last so authentisch wie möglich zu erzeugen, sodass die Muster der Produktivumgebung entsprechen. Denn oft entstehen Datensilos, die als Flaschenhälse die Gesamtperformance verschlechtern. Zum Beispiel senden Lastgeneratoren viele Lese- und Schreibanfragen an ein Frontend-Microservice, wobei das Frontend diese an einen für das Speichern der Daten verantwortlichen Backend-Microservice weiterleitet. Verarbeitet der Frontend-Dienst die Anforderungen nicht effizient genug, wird der Backend-Dienst gar nicht erst ausgelastet. In der Regel sind alle Microservices über mehrere Server verteilt, was alles zusätzlich verkompliziert. Unter allen diesen Bedingungen ist es sehr schwierig, den I/O separater Backend-Systeme zu testen. Darüber hinaus wäre für viele kleine und mittlere Unternehmen eine separate Lasttestumgebung aus Kostengründen gar nicht realisierbar.
Aus diesen Gründen finden Benchmarks oft in der Produktionsumgebung statt. Um daraus einen Wert abzuleiten, werden solche Tests insbesondere während der Stoßzeiten, wenn die Systeme unter hoher Belastung stehen, durchgeführt. Solche Tests sind
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.