Under the timeline above is the “after” example, showing how the team decomposed that SLA—giving each part of the solution its own “performance budget” to tune at the component level. CA’s DevTest allows teams to isolate each of those components by virtualizing the surrounding lab environments (and the expected or observed response times) of other components in the system. Using this method, you can determine, for instance, that the pricing app is delivering excess time to the overall solution; and because you set a budget for the response time, you can take individual corrective steps to tune each component in isolation, faster and at far lower infrastructure cost.
Service virtualization captures and creates realistic, highly scalable and responsive versions of virtual services for any dependent system the performance lab needs to connect to, using whatever tools they currently use for load testing, without requiring coding or reconfiguring new hardware to represent those systems in the performance lab.
Once a virtual service environment (or VSE) has been established, anyone in the development and testing organization can get access to the virtual service to use whenever they need them. No new hardware, no extra access requests, no waiting to start testing or for these multiple teams to have a very current, realistic way to simulate the rest of the application so that performance and load testing can be conducted at a component level – just as if that component were hooked into the rest of the solution.
In CA Service Virtualization, companions can be configured for virtual service think scale, batch response, and recurring think time scale to vary the performance of the virtual service over a period of time. Think time specs specify the response latency. This can be scaled using think time scale during deployment or using companions. High think time specs or think time scale can simulate slow network behavior.