About This Series – This series of articles is a how-to manual on applying performance modelling techniques without any needless discussion of internals or mathematics (with the exception of the necessary but simple Little’s formula which will be included in the 2nd installment of this series). The examples are based on the mBrace model in general performance terms instead of modelling lingo. The mBrace technique was evolved by us here at mBrace. We would sincerely recommend to those of you who intend on digging deeper into applying modelling, that you might consider investing in Dr. Leonid Grinshpan’s book titled, “Solving Enterprise Application Performance Puzzles”.
This series will cover the following topics –
- Do Applications Have Performance DNA
- Hardware resources
- Software resources
- Performance testing
- Agile performance testing
- Measuring performance-DNA
- Measuring CPU by process
You can read the Introduction to this series by Clicking Here.
About the Author : Michael Kok (LinkedIn) lives and works in the Netherlands. His career started in 1965 after obtaining a bachelors degree in electrical engineering. He had various managing and consultancy positions, frequently related to computer performance. In 2005 he decided to further focus on performance engineering and founded the mBrace company (www.mbrace.it) where he is CTO now.
The purpose of performance modelling is to explain the performance of applications and to predict their performance in varying circumstances. Predicting application performance takes knowledge about its performance-DNA. Every application has its unique performance-DNA. So let’s take a look at what does Application Performance DNA look like and why is it interesting?
Many applications are just a set of transactions that subsequently make use of resources, both hardware and software. A transaction is an action of the user which demonstrates consumption of resources for a given response time. For each resource we need to know how long it is engaged by the application in servicing the given user transaction, i.e. for each resource in the hardware chain that the transaction passes. In other words the transaction has a service demand for each resource. The complete series of service demands for one transaction is called a transaction profile. The complete set of all transaction profiles is called the application profile, or as I like to call it the Performance-DNA of the application.
Figure 1: Infrastructure
The next figure depicts in a simplified manner the way time is spent by transactions being processed by the system.
Figure 2: The time spent to process a transaction
The coloured horizontal line in Figure 3 shows a summary of how much time the transaction takes of each of the resources of the infrastructure in Figure 1. Notice that the colours of the horizontal line correspond with the components of the infrastructure shown in Figure 1. Each of the transactions may have such a transaction profile with varying values. The whole set of transaction profiles for all transactions of the application is called the application profile, or as I like to call it: the application’s Performance-DNA.
Figure 3: Profile of one transaction
The transaction profile shows by the total length of the horizontal bar the single user response time of the transaction, which is the lowest possible value of the response time of that transaction.
When the application is used in a high transaction volume its Performance-DNA remains invariant. However that does not mean that the response times remain the same. They will very likely increase. We will later see how that can be explained and estimated.
It is practical to visualise the transaction profiles in a graphical way. Therefore the layout of Figure 3 is reshaped into Figure 4. Again the length of the bar corresponds with the response time and the colours correspond with the colours of the infrastructure components of Figure 1. An application may have dozens even thousands of different transactions, so its Performance-DNA may contain a stack of bars like the one in Figure 4. In most of the cases we only deal with a subset of the transactions when we analyse its performance with the model.
Figure 4: Each application has performance-DNA and for each application this DNA may look different.
The next three examples of varying performance-DNA are shown.
Figure 5: Light weight application with server side response times in the range of 3 to 40 msec.
Each bar shows one transaction profile. The legend shows that there are 5 different CPU’s involved, which means that there are 5 servers involved. The Client PC is not included. So in this case the Performance-DNA is not entirely complete. For each server the service demands for CPU and disk are included as well as the network. Network includes the WAN and all LAN’s, split in inbound and outbound. This example shows extreme short service demands.
Figure 6: An ordinary web application with ordinary response times
Figure 6 shows the performance-DNA of an ordinary web application sorted by decreasing response times. The application runs on an infrastructure with 3 servers. The Client PC is included in the transaction profiles. Transactions 012 and 006 are executed on the Client PC only. The others use the full chain.
Figure 7: An application with long response times.
Figure 7 shows an application with transaction response times varying from 1 up to 70 seconds. The infrastructure has 5 servers. The Client PC and networks are not included in the profiles. In this example the transaction profiles are sorted by process sequence rather than decreasing response times.
In the above examples only subsets of 9 or 11 transactions are shown for the sake of legibility. The numbers of transactions that applications may have vary from dozens to thousands. It is pragmatic to limit the number of transactions in the Performance-DNA when analysing application performance. In practice only the transactions that are used in 95% of the transaction volume are taken and in many cases that is a surprisingly small number. Over the life span of an application new transactions may be added and existing ones may be changed. This can make it necessary to repeat measurements to update the performance DNA as a sort of maintenance.
Obtaining a Performance-DNA or Transaction Profile is not trivial because our industry does not support the concept of transaction. It takes bizarre measurement procedures to collect all elements of the transaction profiles. On many occasions costs are cut by leaving out parts of the profile. The choice of service demands measured may be determined by a risk assessment. At least the elements should be included that are needed to analyse the performance aspects with high risk. As an example the service demands of the Client-PC are often omitted to save time and money.
It is important to bear in mind that when the application software changes its Performance-DNA or its Transaction Profile changes too. So the transaction profiles have to be taken by measurement again each time the software of the transaction is changed. Once we have succeeded in capturing the application’s Performance-DNA the world lies open for analysis of the application’s performance.
The application’s Performance-DNA is invariant a great deal. It will show the same picture in many varying circumstances. E.g. the Performance-DNA remains the same when the transaction volume increases. The exception is with vertical scaling of resources, which will be treated in the third article of this series.
A transaction profile shows the response time for a single user. A single user does not cause any queuing. So the Performance-DNA shows the minimal response times for the application without waiting times. When the transaction volume increases, the response times may increase due to queuing, but the performance-DNA remains the same. Waiting times may come up for each of the resources. So if we want to explicate why a response time is as it appears we first observe its Performance-DNA. In many cases that tells the tale on poor performance already.
When we want to predict how much the application will load the resources we have to fill in two more items: usage volume (number of concurrent users, transactions per second) and hardware configuration or specifications. Commonly the term Workload Characterisation refers to determining both the Performance-DNA and the usage volume of the application.
The next article will outline how usage volume is handled.
As always, your feedback/input/comments are welcome. We would encourage you to share your thoughts/opinions using the chat section below. You can also reach out to me at michael dot kok at mbrace dot it.
Michael Kok (LinkedIn) lives and works in the Netherlands. His career started in 1965 after obtaining a bachelors degree in electrical engineering. He had various managing and consultancy positions, frequently related to computer performance. In 2005 he decided to further focus on performance engineering and founded the mBrace company (www.mbrace.it) where he is CTO now. Michael is the spiritual father of the mBrace methodology and the mBrace model for performance engineering. He frequently participates in performance projects most of them being performance testing projects. Michael is passionate on developing and marketing model based solutions and likes to share his thoughts on the subject.