Get in touch with us
We at accompio will be happy to help you.
22.09.2026
How many users can an application serve simultaneously? For a long time, this question was at the heart of traditional performance testing. Today, this perspective is no longer sufficient.
Cloud-native applications often consist of microservices, containers, Kubernetes clusters and other infrastructure components, which dynamically react to load. Containers are started or stopped, resources are automatically added or reduced, and individual components can influence each other.
Performance Engineering must therefore look at more today than just the response time of a single application. It is about, how the entire system behaves under different load conditions and whether mission-critical processes function reliably even during peak loads.
Tamer Ilgüz is an IT consultant at PrimeTec, a company in the accompio Group. His main areas of focus are performance engineering and performance quality management. In an expert interview, he explains why traditional load tests are reaching their limits, what role the cloud and Kubernetes play, and how companies should adapt their performance strategy to modern, dynamic environments.
In the full expert interview speaks Tamer Ilgüz, IT Consultant at PrimeTec, an accompio Group company, on modern performance engineering and explaining what companies should pay particular attention to when it comes to cloud-native applications.
00:06 Hello and a warm welcome to today's accompio focus topic from Dresden: Performance testing in the cloud era and why more than just the application matters nowadays. With me today is Tamer Ilgüz, a very warm welcome. It's great to have you here. Please feel free to briefly introduce yourself and tell us a little about the challenges that occupy you on a daily basis. I am an IT consultant at PrimeTec. PrimeTec is a company in the accompio group. My main focus areas are performance engineering and performance quality management. I actually deal with the entire chain related to performance.
00:39 That means: the creation of test scripts, of test scenarios, the execution of load tests and, of course, the analysis and optimisation of the application. Beyond that, we also train customers in the field of performance testing, in both theory and practice. The challenge I face nowadays is that performance bottlenecks usually don't just arise in the application. They can also lie in the infrastructure and in the underlying platform as well. And now performance testing has also changed significantly in recent years. What would you say distinguishes performance
01:17 Engineering as we have it today, versus classical load testing? Classical load testing is more of a final acceptance test where you ask the question: How many users can my system support? What is the maximum load that can be placed on the systems? Modern performance engineering goes a bit deeper. It looks at how the system behaves under increasing load, sudden load, or even decreasing load. All components are taken into account, meaning infrastructure as well as platforms such as clouds or Kubernetes are monitored and tested. This differs greatly between the two testing methods,
01:59 Let's call it that for now, and in modern performance engineering, you look at how the system behaves under load. And with traditional load tests, it's more about what the average response times are or what maximum load my system can handle. Can you explain once again why it is not sufficient to exclusively test the performance of individual applications? Well, applications nowadays don't just consist of a single component. An application can have multiple components. And if, for example, one component is slow to respond to a request, it in turn can affect another component. And that in turn affects the entire system.
02:38 That is why one should test and monitor all components and not just one. Okay, and you just touched on it: cloud-native applications frequently consist of microservices, containers, and Kubernetes clusters. What new challenges does this create for performance testing? Yes, the performance tester naturally has to deal with more complex work because you do not have a static system state, but rather the system state is dynamic. Um, containers can be started, stopped, or moved to other nodes at any time. And that naturally makes testing more complex. And Kubernetes and auto-scaling
03:18 ensure that applications react dynamically to load. You just mentioned that a moment ago as well. And how does that change the planning and execution of performance tests? Well, with cloud-native applications, you are already involved in having multiple components. And you have to look more closely at which component is now the bottleneck. And then you also have the problem that I often observe in projects: that the test environment you are testing on does not correspond to the production environment. So it's not realistic enough. But by that I don't mean the size either. The size is actually irrelevant in this case.
03:57 It's more about how the topology, network infrastructure or even the cloud properties are simply configured. Ideally, the test environment should have the same cloud configuration as the production environment so that the measurement results are not distorted either. And are there typical mistakes you observe in companies that do migrate their application to the cloud, but still carry out their performance tests using traditional methods? Yes, a major mistake is that after the application is migrated to the cloud, testing continues as before. And that is naturally disastrous. A new test concept should be created.
04:34 You should adapt your test scenarios. Usually, for example, auto-scaling is not tested. You don't look at all the components. Yes, so you only look at the pure application itself. Normally, you should also monitor and check all components. Most of the time, the test scenarios are also too short. Yes, I recommend that it is best to carry out long-term tests to also see if there are any memory leaks. And those are definitely things that you have to take into account. Okay, and previously the maximum load capacity of the application was the main focus. That has changed too.
05:14 It is more about scaling and system behaviour than pure load limits. How would you categorise that? Yes, the maximum load limit is just a snapshot. That describes the maximum amount of load that can be placed on the systems. Scaling behaviour is more about how the system reacts as the load increases. Does it crash, are new resources added if necessary, or when the load drops again, is the system scaled back down? Those are more the kinds of questions one deals with regarding scalability. Okay, and what role do infrastructure, networks, databases and cloud services play in all of this?
05:58 simply for the overall performance of modern applications? Yes, overall performance depends on all parts. With microservices, for example, important network calls can be relevant. With databases, queues, indexes, queries or the connection pool can be bottlenecks. Also cloud services, load balancing and auto-scaling. These components can, of course, become a bottleneck. Therefore, if you want to assess the overall performance of a system or application, you should ensure that you have an end-to-end measurement result of a transaction that really tests all components as well. Where you can also say: Right, my application is optimal,
06:42 and it can certainly handle high load peaks well and perform accordingly. Okay, and do you happen to have any other tip on how companies can ensure that their applications remain stable even during load peaks and that mission-critical processes in particular continue to function reliably? Yes, first of all, companies should naturally ask themselves: What actually are my mission-critical processes? It is best to prioritise them so that even during a high load peak, I might say, you can restrict the lower-priority mission-critical processes so that the high-priority processes continue to work as well.
07:25 Furthermore, one should also look into SLAs, which means Service Level Agreements. What do I actually expect from my application? How performant does it need to be and how much load or how should the scalability of the system work? So one should also deal with such questions so that the application runs performantly. There I will also jump back to the infrastructure, meaning the test environment. The test environment really has to be mirrored one-to-one with the cloud environment or the production environment. So it should be very, very close to production, so that one can also continue to use the test results that one has for analysis or
08:06 can be used for interpretability. Performance testing is increasingly being integrated into the development process. Why is performance engineering increasingly evolving into a continuous task rather than a final test before go-live? Quite simply, because applications have changed over the last ten years too. That means ten years ago you might have had an update once a year, whether it was a Java update or a cloud update. And nowadays, updates of some kind arrive every two months that simply have to be installed. And then, of course, the developer also asks themselves the question,
08:43 What has the update actually caused in my application? Has the performance improved or has it gotten worse? That is why nowadays one tends to have the task of carrying out continuous testing rather than once a year before every release or before every go-live. That is why I am of the opinion that performance tests should be carried out continuously and not just before every go-live. Which key figures and metrics are then really relevant today when companies want to evaluate the performance of their application? Yes, there isn't just one important metric. Of course, all metrics play an important role.
09:22 Ultimately, it is more about whether the user is satisfied with the application and has a good feeling when using it. Average response times and throughput obviously play an important role here. However, many other performance indicators are also relevant in order to identify certain performance bottlenecks. Okay, and what role does the collaboration between development, operations and quality assurance play in order to ensure performance on an ongoing basis? That actually plays a very, very important role. Development knows its code, operations knows the application and quality assurance knows how to test.
09:58 That is why all three parties should work together towards goals and also tackle issues together instead of against each other. For example, the developer can provide feedback to the performance tester on where there might be certain bottlenecks and which algorithm might still take a little longer, so that the performance tester can naturally validate this and perhaps also make recommendations for optimisation. The topic of artificial intelligence naturally plays a role here too. What role will it play in performance engineering in the future? Well, it is naturally frightening how AI is developing. However, I am of the opinion that,
10:37 that AI should only serve as a supporter and assistant and not completely take over the performance tester's tasks. Of course, you can use AI to evaluate certain charts, for example. In addition, you can use AI to identify certain correlations in charts, or for test script support, or for summarising certain results. But the performance tester definitely still has to interpret it in any case. And cloud-native testing and resilience are becoming increasingly important. Which developments will shape performance engineering in the coming years? Well, performance testing is becoming more and more automated
11:21 and test environments are now only provided on demand. Performance testing as a task in itself is also increasingly being carried out continuously rather than before every go-live. That is definitely a development that is coming our way. And then also that resilience and scalability are moving closer together. Yes, failures are now simulated in systems to check how scalability reacts. What happens in the meantime, for example, when scaling up? Are requests still answered by the system, or do they end up in a queue, or does the system possibly collapse completely under a high load?
12:05 That is definitely also something, namely that resilience and scalability are tested together, and then efficiency as well. Yes, in a cloud environment you can of course keep providing more resources and scale the whole thing up. But economically speaking that is of course not ideal. You also want to save on cloud costs. Therefore, efficiency will also play an important role. This means applications are being developed to be more performant, running efficiently and optimally even with, shall we say, less than ideal resources. Okay, thank you very much. And finally, do you perhaps have any advice for companies that are [developing/shaping] their performance strategy
12:46 want to adapt to modern cloud and Kubernetes environments? Yes, what I often observe in companies is that the first question people always ask is: what test tool should we use? In my opinion, that is the wrong approach. You should instead think about which business-critical processes or transactions are important, and naturally prioritise them. Then you should also ask yourself: what response time or reaction time do I expect? You should definitely define SLAs. You should also not just test the application itself, but look at the whole system as well. That means all components must be tested too, be it auto-scaling,
13:26 Kubernetes, containers, or whatever. So not just focusing on the application itself, but monitoring the entire system. And then, of course, you should also try to design test scenarios where, for example, longer tests are carried out to see if there are any memory leaks. Yes, and perhaps also try to increase the load to see how that affects the scaling behaviour. Those are definitely things that I should consider with an application so that the application functions optimally and satisfactorily. Yes, and that is where we at PrimeTec can of course also support you. We have experienced IT consultants,
14:04 who have been creating such test concepts for years and are also involved with such test scenarios. Yes, and when requests come in, we are of course there and are also happy to support companies or customers. Tamer, thank you very much for the insight into this exciting topic, and thank you very much for listening. And we look forward to hearing you again with the next focus topic.
Traditional load tests primarily answer one question: How much load can a system withstand?
Modern Performance Engineering goes beyond this. It examines how a system behaves under increasing, sudden or decreasing load. In doing so, it looks not only at response times and throughput, but also at infrastructure, databases, network and cloud platforms.
This is particularly important for modern applications because a performance issue does not necessarily have to originate within the application itself. A network, a database, a load balancer or another component of the infrastructure can also become the bottleneck.
„You shouldn't just test the pure application, but also look at the whole system.“
Tamer Ilgüz, IT Consultant at PrimeTec
In cloud-native environments, a system is not static. Containers can be started or stopped, Kubernetes can move resources, and auto-scaling can provide additional capacity depending on the current load.
Performance Tests therefore must also investigate, how the system reacts to changes. Does it actually scale automatically when the load increases? How does the application behave when the load decreases again? And does the scaling also work for individual components?
Having a test environment that is as close to production as possible is crucial here. Differences in network structure, topology, or cloud configuration can mean that test results cannot be readily transferred to production.
The duration of a test also plays a role. Short-term tests can, for example, overlook long-term problems such as memory leaks. Therefore, long-term tests can be an important addition.
Anyone migrating an application to the cloud shouldn't just adopt their existing testing strategy without changes. In an interview, Tamer Ilgüz highlights four mistakes that most frequently limit the validity of performance tests:
Performance shouldn't be checked only just before go-live. Applications and their infrastructure change continuously. An update can, for example, add new features while simultaneously impacting performance.
Regular performance tests help to identify such changes early on. As a result, performance testing becomes more of an integral part of the development and operational process and less of a one-off quality test.
In doing so, companies should above all business-critical processes consider. Not every function is equally important. Clear SLAs allow requirements for response times, load and scalability to be concretely defined.
Performance cannot be ensured permanently by a single team. Development knows the code, operations know the infrastructure, and quality assurance knows the testing processes.
These perspectives must be brought together. For example, known technical bottlenecks can be specifically tested and then resolved together.
AI can also help with analysis in the future, for example in recognising patterns, creating test scripts or evaluating results. However, the expert interpretation of the results remains a key task for the performance tester.
accompio advises you on the integration of performance tests and how they can be adapted to dynamic cloud environments.
Performance testing is increasingly evolving towards automated and continuous testing. At the same time, resilience and efficiency are gaining in importance.
A system must not only handle heavy load, but also scale sensibly while making efficient use of available cloud resources.
This takes the core question beyond mere performance: How performant is the system, how well does it scale, and how efficiently does it use the available resources?
In the cloud era, the performance of an application can no longer be viewed in isolation. Modern systems are dynamic and consist of numerous components that influence one another.
Performance Engineering must therefore entire system to consider. This includes the application, databases, the network, the cloud, Kubernetes, and auto-scaling.
Anyone who merely measures the maximum load limit of an application today is only looking at a part of the performance. What is crucial is how the entire system behaves under realistic conditions.
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 examines the resilience and behaviour of a system. Performance engineering goes further and looks at the interplay between application, infrastructure and platform under varying conditions.
Moderne Anwendungen bestehen aus mehreren miteinander verbundenen Komponenten. Engpässe können beispielsweise auch in Datenbanken, Netzwerken, Cloud-Diensten oder beim Load Balancing entstehen.
Differences in network, topology or cloud configuration can influence the measurement results. An environment that is as production-like as possible makes the results easier to interpret.
Performance tests should not only take place before a go-live. As applications and infrastructure are continuously changed, regular or continuous execution is recommended.
Auto-scaling alters the available resources depending on the load. Performance tests should therefore also check how the system behaves under increasing and decreasing load.
Frequently, existing test concepts are adopted without changes, even though the system architecture has changed. Further mistakes are a non-production-like test environment, missing checks of auto-scaling and infrastructure, as well as tests that are too short and overlook memory leaks.
