The End-User-Transaction
Performance testing can be done on transaction processing or batch processing. In this series of articles I focus on transaction processing. Since there is a lot of confusion where transactions and web requests are mixed up, I’d like to spend some words on it.
Here are some ideas about the phenomenon first:
What is a transaction also known as an end-user-transaction? To me it’s mainly defined by the following features:
- An action by a user on an application that has a response time.
- It consists of one or more web requests.
When testing them we are not interested in the behaviour of some occurrences, we want to know the behaviour of the generic type, the Transaction Type. Since consequent use of the full term can be exhausting I am forgiving when the thing is just called Transaction.
Though our economy runs a great deal on transaction processing, the IT industry seems to ignore it. E.g. in contrast with web requests, which are all neatly defined by a name, transactions don’t get any identification when developed. As a consequence they are under-managed, especially with regard to performance.
While doing the scripting for load and stress testing we give Transaction Types only ad hoc and temporarily a name. Unfortunately this name disappears again after completion of the testing. So when the application has gone live you do not find much relating the transaction types of your application to the vast amounts of data logged by the infrastructure. Let alone that you can easily relate the performance of Transaction Types to the results of your previous performance tests. It takes very special techniques to deal with this problem. There are products that to some extent successfully deal with this.
But why the Transaction Type and why not web requests? Of course I like to obtain performance data on web requests, but I prefer them within the context of a Transaction Type.
The first reason why the Transaction Type is to be considered the central element, is because it has the 1:1 relationship to response time, which again relates 1:1 to the user experience. Since we can have a norm for response time we can formally test the performance of the Transaction Type. If you performance-test a web request you do only half the job and there cannot be formal quittance. Hence for me the sequence is: first get an overview on the level of transactions, then dig into the details like web requests.
Second you get an optimal result when you optimise response time while considering all web requests (can be dozens) of a Transaction Type as a set. You only decide to optimise a web request when you are sure it’s one of the big ones in the Transaction
In my view the focus of a performance test covers the complete Transaction Type in the first place. After you have the overview, you may drill down into its web requests. If necessary.