More into the basics – II

Agreed that was a lot of theory, and since I am no fan of theory myself, here are a few pictorial representations of what we were trying to understand until now.

Throughput:
I was mentioning before that throughput has a maximum, and once it has reached a maximum no additional load can increase the throughput. The following graph illustrates that.

The x-axis represents the load, and the y-axis represents the throughput. We can see that, when the load is 1, the throughput is 1. Relate this to the gift shop we were talking about, when there is one customer, one customer is served by the counter in a minute. Likewise, if there are 3 customers, 3 customers will be served by the shop at the same time (in a minute, in this case). This is the case until we have 5 customers, where the throughput also increases to 5 customers at the same time, as we have 5 counters. Now, if we have more than 5 customers, the throughput stays at 5 – logical, isn’t it? We have only 5 counters, and any customers more than 5 will have to queue up as the maximum number of customers served will be only 5. So here, you can see that once the throughput reaches 5, it stays constant there.

Something worth noting here: throughput basically represents a bottleneck in your system, so to say that something is preventing your system from yielding more results. In this case, we can say that our store’s number of customers processed is limited by the number of counters present in the store. If we need more than 5 customers to be attended to at the same time, we need to take the necessary steps to have that done. But let’s talk about this part later, when we have covered the necessary basics.

Response Time vs Throughput:

Let us now look at the relation between response time, throughput and load (we have covered this theoretically earlier).

You can see what I meant with respect to response times, that the response time is the sum of the waiting time and the processing time. For the first 5 users, the response time is 1 minute, the for the second set of 5 users, the response time is 2 minutes and so on. This illustrates that, as the load increases, the response time increases linearly. Although the throughput stays constant after a certain level, the response times will increase as the load increases.

We have been talking about load for quite some time now, let’s discuss how we decide on the load when we have to performance test an application in the next section.

More into the basics

We were talking about throughput in terms of the store. Taking that forward to the application, throughput will be the total number of bytes sent by the application in a second, and like the store, irrespective of how many requests are thrown at the server, this throughput will not increase beyond a certain limit.

Now, that brings us to the topic of number of users on an application. We see two different terms in load testing, concurrent users and active users. Are they the same? Taking the store example, we have some customers browsing the shelves, and others interacting with the shop personnel. It is evident that all these users are using up the shop floor, although only some of them are interacting with the resources, here the shop personnel. These number of users interacting with the shop personnel will be the active customers, and all the customers using the floor (that inlcudes the active customers as well) are termed concurrent customers.

Concurrent users: Concurrent users refer to users who have logged into the system irrespective of whether or not they are doing anything on the system.

Active users: Active users are a subset of concurrent users who are logged in and are performing some action at a specific point in time.

Note: These definitions vary across the world, and when a bunch of people get together to talk about these terms, it is prudent to agree on what the terms mean.

Let us now relate response times, throughput and users in layman terms. In the store, the person in front of the queue has a response time of 1 minute. For the second person in the queue, to complete his purchase, he has to wait for the customer in the front to complete his purchase (1 min) and then purchase his item (1 min). So that adds up to 2 minutes for the second person in the queue. Likewise, for the 5th person in the queue, it will take 5 minutes before his purchase is complete.

The same logic applies to a website as well. Let us assume that the website can process 100 requests per second (this will be the throughput of the website, in case you haven’t yet grasped the concept), the 101-st request will have to wait one of the earlier requests is processed, so the response time for this request will 2 seconds. That boils down to the conclusion that the response time of a transaction is the sum of waiting time and the request processing time.

This is too much of theory, so let’s see a few graphs in the next part that will illustrate how throughput looks and how response times look with increase in the number of users.

Beginning with the definitions…

Let’s try to understand what we try and measure in a typical load test, and build the definitions from there. To make it simple, I’ll give an example of a real-time shop which we can then map to a software.

Visualize a large shop that sells gift articles. As you can see, there are a number of customers in the shop, each performing one of the three possible things you could do in a gift shop – look around for a suitable gift, ask a store assistant for help or purchase a gift. As it is a gift shop, you may also see people near the gift wrapping section. If we analyze the effective interactions between the store personnel and the customers, it will be where customers ask the assistant for help, or when they purchase something at the counter. Worth noting is the fact that not all customers end up buying something from the store.

Now that divides the interactions into two major categories – people looking at stuff by themselves, and people interacting with the shop employees. The store has to accommodate and should be able to serve all the customers in order to keep its business running.

This is analogous to an online application, where there are a number of users on the site: a large number of them would be browsing pages that they have downloaded, some using the search button or a help button to avail more options, and a few of them purchasing items they are interested in. The website should be able to handle all the users connected to the website, to be able to retain the customer base.

For the present, let us focus on people actually purchasing items from the shop. There are 5 counters in the shop, with 5 shop assistants behind the counters. On a busy day, there will be a queue of customers in front of the counters waiting to be served. Each assistant typically gets the article from the customer, looks up the price, gets the money from the customer, generates a receipt and hands over the article and the receipt to the customer. (We are assuming here for the sake of simplicity that each customer gets only one article) Lets guesstimate the time taken here, it may take around a minute for an experienced assistant to complete the purchase process. So, for a customer, it takes 60 seconds to purchase an article from the shop.

If we compare this to an online store, after a user selects a particular item he is interested in and fills in all the relevant details such as his name, card-details, address etc and submits a request, the website takes some time to process this request, say n seconds. Now this is the response time of the website pertaining to the purchase action, which otherwise is called the purchase transaction.

Response Time: Response Time is time duration between the time a customer submits a request to the application and the time he gets a response back from the application.

Transaction: Transaction is an action or a set of related actions performed to complete a particular process, in this case, purchasing an item.

As is obvious from the scenario we just saw, there are 5 counters, and hence at any point of time, there can be a maximum of 5 purchases made from the shop, each taking a minute. To talk in simple terms, the shop will be able to complete 5 purchases in a minute. This will not change with the length of the queue, any increase in the number of customers will not increase the number of purchases that can be completed in a minute. This number will be our throughput for the store, the total number of purchases completed per unit of time, in this case a minute.

Throughput: Throughput is measured as the amount of work done by an application in a given time frame or per unit of time.

You can guess how this compares with an online site easily, but if you cant, hasten not mate, we will build on this scenario to understand the application architecture better.

The basics of the whole thing

Ok, now that this blog is all about Load Testing, let’s not go about beating the bush and get on with the building blocks in simple terms.

Let’s just say some product company or a commercial website company comes up with a new application. Now according to software methodologies and all that loads of jargons in the industry, there could be three tiers in the overall architecture. The first tier is what we get to access, the front-end, the beautiful colorful userfriendly interface that you’d work with as the end-user. The second tier is the place where all the business logic is stored, the brain behind the application, hidden from you. The third tier is the data-store, which feeds the mid-tier and gets from it, the data pertaining to the application – this will be the innermost block of all. After all data is supposed to be critical and secure, right?

All these blocks together have to be perfect, oh did I say perfect?, close to perfect to make this application act good in your hands. So, that will mean we check if the individual blocks do what they are supposed to do, and if they talk friendly to each other and are behaving themselves. This tough part is done by the functional testers, the enthusiastic and patient folks.

Then comes the easier part, the application is alive and kicking and the blocks interact well with each other but are we sure that they are going to behaving well with us, the end-users? Mind you, we are Gods in this context (most companies have customer is god policy, luckily for us), so we are not going to like it if the application takes a long time to respond to us, or if it gives us that devilish message saying that the server is unavailable. So the company’s got to ensure that the application is friendly to humans as well!

And that’s what performance testing is all about. We check if the blocks are communicating faster, and can handle the scores of different homo-sapiens who keep demanding data from the application, without running out of energy and food supply. Oh yes, also that the human user gets a response within an expected time-frame. Now, that doesn’t look tough, does it?