Kontaktieren Sie uns
Wir von accompio helfen Ihnen gerne.
22.09.2026
Wie viele Nutzer kann eine Anwendung gleichzeitig bedienen? Diese Frage stand beim klassischen Performance Testing lange im Mittelpunkt. Heute reicht diese Betrachtung nicht mehr aus.
Cloud-native Anwendungen bestehen häufig aus Microservices, Containern, Kubernetes-Clustern und weiteren Infrastrukturkomponenten, die dynamisch auf Last reagieren. Container werden gestartet oder beendet, Ressourcen werden automatisch hinzugefügt oder reduziert und einzelne Komponenten können sich gegenseitig beeinflussen.
Performance Engineering muss deshalb heute mehr betrachten als nur die Antwortzeit einer einzelnen Anwendung. Es geht darum, wie sich das gesamte System unter unterschiedlichen Lastsituationen verhält und ob geschäftskritische Prozesse auch bei Lastspitzen zuverlässig funktionieren.
Tamer Ilgüz ist IT-Consultant bei PrimeTec, einem Unternehmen der accompio-Gruppe. Seine Schwerpunkte liegen im Performance Engineering und Performance Quality Management. Im Experteninterview erklärt er, warum klassische Lasttests an Grenzen stoßen, welche Rolle Cloud und Kubernetes spielen und wie Unternehmen ihre Performance-Strategie an moderne, dynamische Umgebungen anpassen sollten.
Im vollständigen Experteninterview spricht Tamer Ilgüz, IT-Consultant bei PrimeTec, einem Unternehmen der accompio-Gruppe, über modernes Performance Engineering und erklärt, worauf Unternehmen bei Cloud-native Anwendungen besonders achten sollten.
00:06 Hallo und herzlich willkommen zum heutigen accompio Fokusthema aus Dresden: Performance Testing im Cloud-Zeitalter und warum heute mehr als nur die Anwendung zählt. Bei mir ist heute Tamer Ilgüz herzlich willkommen. Schön, dass du da bist. Stell dich gerne kurz vor und erzähl ein bisschen was zu den Herausforderungen, die dich so tagtäglich beschäftigen. Ich bin IT-Consultant bei PrimeTec. PrimeTec ist ein Unternehmen der accompio-Gruppe. Meine Schwerpunkte liegen im Bereich Performance Engineering und Performance Quality Management. Eigentlich befasse ich mich mit der gesamten Kette, die mit Performance zu tun hat.
00:39 Das heißt: das Erstellen von Test-Skripten, von Testszenarien, die Durchführung von Lasttests und auch natürlich die Analyse und Optimierung der Anwendung. Darüber hinaus bilden wir auch Kundinnen und Kunden aus im Bereich Performance Testing, sowohl in der Theorie als auch in der Praxis. Meine Herausforderung, die ich heutzutage habe, ist, dass Performance-Engpässe meist nicht nur in der Anwendung entstehen können. Die können auch in der Infrastruktur und auch in der darunterliegenden Plattform liegen. Und jetzt hat sich Performance Testing ja auch in den letzten Jahren stark verändert. Was würdest du sagen, unterscheidet Performance
01:17 Engineering, wie wir es heute haben, von klassischen Lasttests? Also klassische Lasttests sind ja eher ein abschließender Abnahmetest, wo man sich die Frage stellt: Wie viele User kann mein System tragen? Was ist die Last, die maximal auf den Systemen ausgeübt werden kann? Beim modernen Performance Engineering geht man noch mal ein bisschen tiefer. Man schaut sich an, wie verhält sich das System bei steigender Last, bei plötzlicher Last oder auch bei Last, die wieder sinkt. Man beachtet dabei alle Komponenten, das heißt Infrastruktur und auch Plattformen wie Clouds oder auch Kubernetes werden dabei überwacht und geprüft. Das unterscheidet sich stark zwischen den beiden Testmethoden,
01:59 nenne ich das jetzt mal, und beim modernen Performance Engineering schaut man, wie sich das System bei Last verhält. Und bei klassischen Lasttests geht es eher darum, was sind die durchschnittlichen Antwortzeiten oder was kann mein System maximal tragen? Kannst du noch mal erläutern, warum es nicht ausreicht, ausschließlich die Performance einzelner Anwendungen zu testen? Ja, Anwendungen bestehen heutzutage nicht nur aus einer einzelnen Komponente. Eine Anwendung kann mehrere Komponenten haben. Und wenn beispielsweise eine Komponente langsam auf eine Anfrage reagiert, kann es wiederum eine andere Komponente beeinflussen. Und das wiederum beeinflusst das gesamte System.
02:38 Deshalb sollte man alle Komponenten testen und überwachen und nicht nur eins. Okay, und du hast es gerade schon angesprochen: Cloud-native Anwendungen bestehen häufig aus Microservices, Containern und Kubernetes-Clustern. Welche neuen Herausforderungen entstehen dadurch für das Performance Testing? Ja, der Performance-Tester hat dann natürlich mit komplexerer Arbeit zu tun, weil man keinen statischen Systemzustand hat, sondern der Systemzustand dynamisch ist. äh, es können jederzeit Container gestartet, gestoppt oder auch auf andere Nodes verschoben werden. Und das macht dann natürlich das Testen komplexer. Und Kubernetes und Auto-Scaling
03:18 sorgen dafür, dass Anwendungen dynamisch auf Last reagieren. Das hast du gerade eben auch schon erwähnt. Und wie verändert das die Planung und Durchführung der Performance Tests? Ja, durch Cloud-native Anwendungen ist man halt schon damit involviert, dass man ja mehrere Komponenten hat. Und man muss genauer hinschauen, welche Komponente jetzt der Engpass ist. Und dann hat man halt auch noch das Problem, das ich viel in Projekten beobachte: dass die Testumgebung, auf der man testet, nicht der Produktionsumgebung entspricht. Also nicht genug realitätsnah. Damit meine ich aber auch nicht die Größe. Die Größe ist in diesem Falle zwar irrelevant.
03:57 Es geht da eher darum, wie die Topologie, die Netzwerk-Infrastruktur oder auch die Cloud-Eigenschaften einfach konfiguriert werden. Im besten Falle sollte die Testumgebung dieselbe Cloud-Konfiguration haben wie die Produktionsumgebung, damit auch die Messergebnisse nicht verfälscht werden. Und gibt es typische Fehler, die du bei Unternehmen beobachtest, die ihre Anwendung zwar in die Cloud verlagern, ihre Performance-Tests aber nach klassischen Methoden durchführen? Ja, ein großer Fehler ist, dass, nachdem die Anwendung in die Cloud verlagert wird, weiterhin getestet wird wie früher. Und das ist natürlich fatal. Man sollte ein neues Testkonzept erstellen.
04:34 Man sollte seine Testszenarien anpassen. Meistens wird dann beispielsweise nicht das Auto-Scaling getestet. Man schaut nicht nach allen Komponenten. Ja, also man schaut dann nur auf die reine Anwendung. Man sollte normalerweise alle Komponenten auch überwachen und überprüfen. Meistens sind auch die Testszenarien zu kurz. Ja, da empfehle ich, dass man am besten Langzeittests durchführt, um halt auch zu schauen, ob es irgendwelche Memory Leaks bzw. Speicherlecks gibt. Und das sind auf jeden Fall Dinge, die man beachten muss. Okay, und jetzt stand früher die maximale Belastbarkeit der Anwendung im Mittelpunkt. Das hat sich ja auch verändert.
05:14 Es geht mehr in Richtung Skalierung und Systemverhalten als um reine Lastgrenzen. Wie würdest du das einordnen? Ja, die maximale Lastgrenze ist ja nur eine Momentaufnahme. Das beschreibt, wie viel Last auf den Systemen maximal ausgeübt werden kann. Beim Skalierungsverhalten geht es eher darum, wie sich das System bei steigender Last verhält. Bricht es zusammen, werden eventuell neue Ressourcen hinzugefügt, oder wenn die Last wieder sinkt, wird das System wieder gedrosselt. Das sind dann eher Fragen, mit denen man sich bei der Skalierbarkeit beschäftigt. Okay, und welche Rolle spielen dabei Infrastruktur, Netzwerk, Datenbanken, Clouddienste
05:58 einfach für die Gesamtperformance moderner Anwendungen? Ja, die Gesamtperformance hängt ja von allen Teilen ab. Bei Microservices können beispielsweise wichtige Netzwerkaufrufe relevant sein. Bei Datenbanken Queues, Indizes, Abfragen oder auch der Connection Pool können Engpässe sein. Auch Clouddienste, Load Balancing und Auto-Scaling. Diese Komponenten können dabei natürlich zum Bottleneck werden. Deshalb sollte man, wenn man die Gesamtperformance beurteilen möchte, eines Systems oder einer Anwendung, dafür sorgen, dass man ein End-to-End Messergebnis hat von einer Transaktion, die wirklich halt auch alle Komponenten testet. Wo man auch sagen kann: So, meine Anwendung ist optimal,
06:42 und sie kann auf jeden Fall gut mit hohen Lastspitzen umgehen und kann auch dementsprechend performen. Okay, und hast du da quasi noch einen Tipp, wie Unternehmen sicherstellen können, dass die Anwendungen auch bei Lastspitzen stabil bleiben und gerade auch geschäftskritische Prozesse zuverlässig funktionieren? Ja, zuerst sollten Unternehmen sich natürlich die Frage stellen: Was sind denn überhaupt meine geschäftskritischen Prozesse? Am besten sollte man diese priorisieren, damit man auch bei hoher Lastspitze, ich sage mal, die niedrig priorisierten geschäftskritischen Prozesse einschränken kann, damit dann auch die hoch priorisierten Prozesse weiterhin funktionieren.
07:25 Außerdem sollte man sich auch mit den SLAs, also mit den Service Level Agreements, beschäftigen. Was erwarte ich denn eigentlich von meiner Anwendung? Wie performant muss sie denn sein und wie viel Last oder wie sollte denn die Skalierbarkeit des Systems funktionieren? Also man sollte sich auch mit solchen Fragen beschäftigen, damit die Anwendung performant läuft. Da springe ich jetzt auch noch mal auf die Infrastruktur, also die Testumgebung. Die Testumgebung muss halt wirklich der Cloud-Umgebung oder der Produktivumgebung eins zu eins widergespiegelt sein. Also sie sollte sehr, sehr produktionsnah sein, damit man halt auch die Testergebnisse, die man hat, weiterhin für die Analyse oder
08:06 für die Interpretierbarkeit nutzen kann. Performance Testing wird zunehmend in den Entwicklungsprozess integriert. Warum entwickelt sich Performance Engineering immer stärker zu einer kontinuierlichen Aufgabe statt zu einem abschließenden Test vor dem Go-Live? Das liegt einfach daran, dass sich in den letzten zehn Jahren auch die Anwendungen verändert haben. Das heißt, man hat vor zehn Jahren vielleicht einmal im Jahr ein Update gehabt, sei es ein Java-Update oder ein Cloud-Update. Und heutzutage kommen alle zwei Monate irgendwelche Updates, die einfach installiert werden müssen. Und dann stellt sich natürlich auch der Entwickler die Frage,
08:43 was hat das Update jetzt bei meiner Anwendung verursacht? Ist die Performance besser geworden oder hat sie sich verschlechtert? Deshalb hat man heutzutage eher die Aufgabe, kontinuierlich Tests durchzuführen, statt einmal im Jahr vor jedem Release oder vor jedem Go-Live. Deshalb bin ich der Meinung, dass man die Performance-Tests kontinuierlich durchführt und nicht nur vor jedem Go-Live. Welche Kennzahlen und Messgrößen sind heute dann wirklich relevant, wenn Unternehmen die Performance ihrer Anwendung bewerten möchten? Ja, es gibt nicht die eine wichtige Kennzahl. Natürlich spielen alle Kennzahlen eine wichtige Rolle.
09:22 Im Endeffekt geht es eher darum, ob der Nutzer mit der Anwendung zufrieden ist und ein gutes Gefühl dabei hat, wenn er die Anwendung nutzt. Da spielen natürlich durchschnittliche Antwortzeiten und Durchsatz eine wichtige Rolle. Aber auch viele andere Performanceindikatoren sind relevant, um gewisse Performance-Engpässe zu erkennen. Okay, und welche Rolle spielt dabei die Zusammenarbeit von Entwicklung, Betrieb und Qualitätssicherung, um Performance eben dauerhaft sicherzustellen? Das spielt tatsächlich eine sehr, sehr wichtige Rolle. Die Entwicklung kennt ihren Code, der Betrieb die Anwendung und die Qualitätssicherung, weiß, wie zu testen ist.
09:58 Deshalb sollten alle drei Parteien gemeinsam an Zielen arbeiten und sich auch gemeinsam mit Fragestellungen beschäftigen statt gegeneinander. Beispielsweise kann der Entwickler Feedback geben an den Performance-Tester, wo es eventuell gewisse Engpässe gibt und welcher Algorithmus doch noch etwas länger braucht, damit der Performance-Tester dies auch natürlich validieren und auch vielleicht Optimierungsempfehlungen abgeben kann. Das Thema künstliche Intelligenz spielt natürlich auch hierbei eine Rolle. Welche Rolle wird sie zukünftig im Performance Engineering spielen? Ja, es ist natürlich erschreckend, wie sich KI weiterentwickelt. Ich bin aber der Meinung,
10:37 dass KI nur als Unterstützer und als Assistent dienen sollte und nicht die Aufgaben des Performance-Testers komplett übernehmen. Man kann natürlich KI nutzen, um beispielsweise gewisse Grafiken auszuwerten. Außerdem kann man KI nutzen, um bei Grafiken gewisse Korrelationen ausfindig zu machen oder bei der Testskript-Unterstützung oder Zusammenfassung gewisser Ergebnisse. Aber interpretieren muss es trotzdem auf jeden Fall der Performance-Tester. Und Cloud-native Testing und Resilienz gewinnen immer mehr an Bedeutung. Welche Entwicklungen werden das Performance Engineering in den kommenden Jahren prägen? Also, Performance Testing wird immer weiter automatisiert
11:21 und Testumgebungen werden nur noch bei Bedarf bereitgestellt. Auch das Performance-Testen als Aufgabe an sich wird immer mehr kontinuierlich durchgeführt statt vor jedem Go-Live. Das ist auf jeden Fall eine Entwicklung, die auf uns zukommt. Und dann auch, dass Resilienz und Skalierbarkeit immer näher zusammenrücken. Ja, man simuliert mittlerweile Störungen bei Systemen, um zu überprüfen, wie die Skalierbarkeit reagiert. Was passiert in der Zwischenzeit, wenn beispielsweise hochskaliert wird? Werden Anfragen weiterhin vom System beantwortet, oder landen sie in einer Warteschlange, oder bricht das System eventuell bei einer hohen Last komplett zusammen?
12:05 Das ist auf jeden Fall auch etwas, also dass man Resilienz und die Skalierbarkeit gemeinsam testet und dann auch noch die Effizienz. Ja, man kann natürlich in der Cloud-Umgebung immer weiter Ressourcen zur Verfügung stellen und das Ganze hochskalieren. Aber wirtschaftlich gesehen ist das natürlich nicht ideal. Man möchte ja auch Cloud-Kosten sparen. Deshalb wird auch Effizienz eine wichtige Rolle spielen. Das heißt, Anwendungen werden performanter entwickelt, die auch bei ich sag mal, nicht so guten Ressourcen performant und optimal laufen. Okay, vielen Dank. Und zum Abschluss hast du vielleicht noch einen Rat an Unternehmen, die ihre Performance-Strategie
12:46 an moderne Cloud- und Kubernetes-Umgebungen anpassen möchten? Ja, was ich oft bei Unternehmen beobachte, ist, dass man zuerst immer die Frage stellt: Was nehmen wir als Testtool? Das ist meiner Meinung nach ein falscher Ansatz. Man sollte sich eher Gedanken darüber machen, welche geschäftskritischen Prozesse oder Transaktionen wichtig sind, und diese auch natürlich priorisieren. Dann sollte man sich auch die Frage stellen: Was erwarte ich an Antwortzeit oder Reaktionszeit? Man sollte auf jeden Fall SLAs definieren. Man sollte auch nicht nur die reine Anwendung testen, sondern sich auch das ganze System anschauen. Das heißt, alle Komponenten müssen mitgetestet werden, sei es Auto-Scaling,
13:26 Kubernetes, Container oder was auch immer. Also nicht nur sich da auf die Anwendung fixieren, sondern das ganze System überwachen. Und dann sollte man halt natürlich auch versuchen, Testszenarien zu gestalten, wo man beispielsweise längere Tests durchführt, um zu schauen, ob es Speicherlecks gibt. Ja, vielleicht auch versucht, die Last zu steigern, um zu schauen, wie sich das auf das Skalierungsverhalten auswirkt. Das sind auf jeden Fall Dinge, die ich beachten sollte bei einer Anwendung, damit halt die Anwendung optimal und zufriedenstellend funktioniert. Ja, und da können wir natürlich auch als PrimeTec unterstützen. Wir haben erfahrene IT-Berater,
14:04 die schon seit Jahren solche Testkonzepte erstellen und sich auch mit solchen Testszenarien beschäftigen. Ja, und wenn Anfragen da sind, sind wir natürlich da und unterstützen auch die Unternehmen oder auch die Kunden gerne. Tamer, ganz herzlichen Dank für den Einblick in dieses spannende Thema und Ihnen vielen Dank fürs Zuhören. Und wir hören uns gerne wieder mit dem nächsten Fokusthema.
Klassische Lasttests beantworten vor allem eine Frage: Wie viel Last hält ein System aus?
Modernes Performance Engineering geht darüber hinaus. Es untersucht, wie sich ein System bei steigender, plötzlicher oder wieder sinkender Last verhält. Dabei werden nicht nur Antwortzeiten und Durchsatz betrachtet, sondern auch Infrastruktur, Datenbanken, Netzwerk und Cloud-Plattformen.
Das ist besonders bei modernen Anwendungen wichtig, weil ein Performance-Problem nicht zwangsläufig in der Anwendung selbst entstehen muss. Auch ein Netzwerk, eine Datenbank, ein Load Balancer oder ein anderer Bestandteil der Infrastruktur kann zum Bottleneck werden.
„Man sollte nicht nur die reine Anwendung testen, sondern sich auch das ganze System anschauen.“
Tamer Ilgüz, IT-Consultant bei PrimeTec
In Cloud-native Umgebungen ist ein System nicht statisch. Container können gestartet oder beendet werden, Kubernetes kann Ressourcen verschieben und Auto-Scaling kann abhängig von der aktuellen Last zusätzliche Kapazitäten bereitstellen.
Performance Tests müssen deshalb auch untersuchen, wie das System auf Veränderungen reagiert. Wird bei steigender Last tatsächlich automatisch skaliert? Wie verhält sich die Anwendung, wenn die Last wieder zurückgeht? Und funktioniert die Skalierung auch bei einzelnen Komponenten?
Eine möglichst produktionsnahe Testumgebung ist dabei entscheidend. Unterschiede bei Netzwerkstruktur, Topologie oder Cloud-Konfiguration können dazu führen, dass Testergebnisse nicht ohne Weiteres auf die Produktion übertragbar sind.
Auch die Dauer eines Tests spielt eine Rolle. Kurzfristige Tests können beispielsweise langfristige Probleme wie Speicherlecks übersehen. Deshalb können Langzeittests eine wichtige Ergänzung sein.
Wer eine Anwendung in die Cloud verlagert, sollte das bisherige Testkonzept nicht unverändert übernehmen. Tamer Ilgüz nennt im Interview vier Fehler, die die Aussagekraft von Performance Tests besonders häufig einschränken:
Performance sollte nicht erst unmittelbar vor dem Go-Live geprüft werden. Anwendungen und ihre Infrastruktur verändern sich kontinuierlich. Ein Update kann beispielsweise neue Funktionen hinzufügen, gleichzeitig aber auch die Performance beeinflussen.
Regelmäßige Performance Tests helfen dabei, solche Veränderungen frühzeitig zu erkennen. Dadurch wird Performance Testing stärker zu einem Bestandteil des Entwicklungs- und Betriebsprozesses und weniger zu einem einmaligen Qualitätstest.
Dabei sollten Unternehmen vor allem ihre geschäftskritischen Prozesse betrachten. Nicht jede Funktion ist gleich wichtig. Durch klare SLAs lassen sich Anforderungen an Antwortzeiten, Last und Skalierbarkeit konkret definieren.
Performance lässt sich nicht dauerhaft von einem einzelnen Team sicherstellen. Die Entwicklung kennt den Code, der Betrieb die Infrastruktur und die Qualitätssicherung die Testprozesse.
Diese Perspektiven müssen zusammengeführt werden. So können beispielsweise bekannte technische Engpässe gezielt getestet und anschließend gemeinsam behoben werden.
Auch KI kann künftig bei der Analyse unterstützen, beispielsweise beim Erkennen von Zusammenhängen, bei der Erstellung von Testskripten oder bei der Auswertung von Ergebnissen. Die fachliche Interpretation der Ergebnisse bleibt jedoch eine zentrale Aufgabe des Performance-Testers.
accompio berät Sie bei der Integration von Performance Tests und wie sie sich an dynamische Cloud-Umgebungen anpassen lassen.
Performance Testing entwickelt sich zunehmend in Richtung automatisierter und kontinuierlicher Tests. Gleichzeitig gewinnen Resilienz und Effizienz an Bedeutung.
Ein System muss nicht nur hohe Last bewältigen, sondern auch sinnvoll skalieren und dabei die verfügbaren Cloud-Ressourcen effizient nutzen.
Damit geht die zentrale Frage über die reine Performance hinaus: Wie performant ist das System, wie gut skaliert es und wie effizient nutzt es die verfügbaren Ressourcen?
Im Cloud-Zeitalter lässt sich die Performance einer Anwendung nicht mehr isoliert betrachten. Moderne Systeme sind dynamisch und bestehen aus zahlreichen Komponenten, die sich gegenseitig beeinflussen.
Performance Engineering muss deshalb das gesamte System betrachten. Dazu gehören die Anwendung, Datenbanken, das Netzwerk, die Cloud, Kubernetes und Auto-Scaling.
Wer heute nur die maximale Lastgrenze einer Anwendung misst, betrachtet nur einen Teil der Performance. Entscheidend ist, wie sich das gesamte System unter realistischen Bedingungen verhält.
Tamer Ilgüz ist IT-Consultant bei PrimeTec, einem Unternehmen der accompio-Gruppe, und berät Unternehmen dabei, Performance Tests sinnvoll in moderne Entwicklungsprozesse zu integrieren.
Performance Testing untersucht die Belastbarkeit und das Verhalten eines Systems. Performance Engineering geht weiter und betrachtet das Zusammenspiel von Anwendung, Infrastruktur und Plattform unter unterschiedlichen Bedingungen.
Moderne Anwendungen bestehen aus mehreren miteinander verbundenen Komponenten. Engpässe können beispielsweise auch in Datenbanken, Netzwerken, Cloud-Diensten oder beim Load Balancing entstehen.
Unterschiede bei Netzwerk, Topologie oder Cloud-Konfiguration können die Messergebnisse beeinflussen. Eine möglichst produktionsnahe Umgebung macht die Ergebnisse besser interpretierbar.
Performance Tests sollten nicht nur vor einem Go-Live stattfinden. Da Anwendungen und Infrastruktur kontinuierlich verändert werden, empfiehlt sich eine regelmäßige beziehungsweise kontinuierliche Durchführung.
Auto-Scaling verändert die verfügbaren Ressourcen abhängig von der Last. Performance Tests sollten deshalb auch überprüfen, wie sich das System bei steigender und sinkender Last verhält.
Häufig werden bestehende Testkonzepte unverändert übernommen, obwohl sich die Systemarchitektur verändert hat. Weitere Fehler sind eine nicht produktionsnahe Testumgebung, fehlende Prüfungen von Auto-Scaling und Infrastruktur sowie zu kurze Tests, die Speicherlecks übersehen.
