Within the discipline of software performance engineering (SPE), application response time monitoring refers to the capability of instrumenting application requests, transactions and other vital interaction scenarios in order to measure their response times. There is no single, more important performance measurement than application response time, especially in the degree which the consistency and length of application response time events reflect the user experience and relate to customer satisfaction. All the esoteric measurements of hardware utilization that Perfmon revels in pale by comparison.
Of course, performance engineers usually still want to be able to break down application response time into its component parts, one of which is CPU usage. Other than the Concurrency Visualizer that is packaged with the Visual Studio Profiler that was discussed in the previous post, there are few professional-grade, application response time monitoring and profiling tools that exploit the …
This series of blog posts picks up on a topic I made mention
of earlier, namely scalability models,
where I wrote about how implicit models of application scalability often impact
the kinds of performance tests that are devised to evaluate the performance of an
application. As discussed in that earlier blog post, sometimes the influence of
the underlying scalability model is subtle, often because the scalability model
itself is implicit. In the context of performance testing, my experience is
that it can be very useful to render the application’s performance and
scalability model explicitly. At the very least, making your assumptions
explicit opens them to scrutiny, allowing questions to be asked about their
validity, for example.
The example I used in that earlier discussion was the
scalability model implicit when employing stress test tools like HP LoadRunner and
Soasta CloudTest against a web-based application. Load testing by successively
increasing the arrival rate of customer r…
This is a continuation of a series of blog posts on VMware memory management. The previous post in the series is here.
Ballooning Ballooning is a complicated topic, so bear with me if this post is much longer than the previous ones in this series.
As described earlier, VMware installs a balloon driver inside the guest OS and signals the driver to begin to “inflate” when it begins to encounter contention for machine memory, defined as the amount of free machine memory available for new guest machine allocation requests dropping below 6%. In the benchmark example I am discussing here, the Memory Usage counter rose to 98% allocation levels and remained there for duration of the test while all four virtual guest machines were active.
Figure 7, which shows the guest machine Memory Granted counter for each guest, with an overlay showing the value of the Memory State counter reported at the end of each one-minute measurement interval, should help to clarify the state of VMware memory-managemen…