Performance Test Unleashed

Just another WordPress.com weblog

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.

October 4, 2007 Posted by | The Basics | , , | 1 Comment

   

Follow

Get every new post delivered to your Inbox.