Volumes!

As I read through my last blog on Performance Engineering just now, I realize that it was still not all that simplified anyway! I ended up using words and phrases like "capacity", "monitoring", "Volumes", "spikes of usage", "end user experience", "queuing principles", "queuing delay", "available"! Let me try to delve deeper into what these phrases mean.


In this edition let's focus on "Volumes".

When a software system is being built it is designed with a specific set of end users in mind. Like for example a fruit vendor decides that he will sell only apples and bananas, likewise, the designer of a software system builds the system to cater to the needs of a specific subset of end-users.

The fruit vendor has a choice, he could go door to door and sell; OR he could sit in a market and offer his fruits whilst customers came to buy them from him. Similarly, the software system could be a single user application like Wordpad or Notepad; i.e. an application used by a single user at a time; OR it could be one that can be accessed by multiple users at once; for example a chat application or a website.


The fruit vendor could decide that he wanted to sell 20 kgs of fruits each day. Similarly, when we define volumes for a system, in a software performance engineering context, we really aim to define the number of end users that will use the software application.


The fruit vendor would typically know that most people would buy fruits from him in the market while they are going to work or during lunch time or later in the evening when they are returning back home. Similarly, define the usage pattern of end users. For eg. If there are 10 users in a small office who will access the "attendance" system; it is very clear that the "attendance" system will receive most of the usage when users come into office in the morning and when users go home in the evening. All through the remaining part of the day the system is "idle".

Today when everything is web based and the world is a global village wherein 2 users of the same application sit in different corners of the world to access the same application, it is imperative that usage is understood from a global perspective. Now let's think that this small office is operating from 2 locations; 5 employees in UK and 5 employees in India. Time zones come into picture here and you will see the access pattern different - Indian employees will access this attendance system in the morning and evening as per India time and employees in UK will do likewise in UK time; thereby making the usage pattern quite different.


If the fruit vendor aims to build a chain of shops that he owns, he needs to understand how many people in different parts of the town would like to have his fruits! So then, taking this analogy forward, we aim to understand how the end users of a software application will grow. Going back to our attendance system as an example, maybe the office is aiming to expand into other parts of the world with more employees. So, what are these plans as per estimates given by the business?


As the total user base grows; the total number of users accessing the system concurrently also grows. Obviously, if the fruit vendor became popular he can expect more people in his store at once! Usually these are directly propotional quantities/ metrics.


So then, to summarize, when we define requirements for a software system, "Volumes" now form an important measure to quantify; and this measure can be defined in terms of

• growing end-users year on year
• number of users using the software system concurrently and
• the pattern of peaks and troughs that is expected

Performance Engineering!

More often than not, I am posed this question by so many people "What do you do?"
And I reply "I am a Performance Engineer"
"Oh, Software Engineer?" pat comes the reply.
"No, Performance Engineering is different" goes the response in my head; but I seldom respond like that.

Rather, I end up saying "Yes"; just to avoid having to answer some tougher questions; or rather to avoid having to think up tough answers to simple questions! The problem is not that the questions are tough; neither are the answers tough, the problem is how do I make the answers simple enough for a layman to understand?

So, let me start my Techie Insight by trying to do just that - Explain "Performance Engineering" as easily and simply as possible. In fact, it should not be that tough because we practice it everytime; in our day to day lives, without knowing it. Really? Indeed, let's check this out.

1. When we see the level of sugar in the sugar can going down, we intuitively know that we have to go and refresh the contents otherwise we will end up with no sugar for tea one day.
2. In fact, when we expect guests at home, we often check all the provisions at home to see we have enough to serve our guests well and that we will not run out of items at the wrong time.
3. We are upset if we are unable to extend warm hospitality to our guests
4. When we go to the bus stop; we usually check the queue that's moving faster and join into that queue.
5. If there is an accident on the road, we see some delay while driving past that part of the road, because some part of the road is blocked off for investigations.
6. We don't like to wait too long at the check-out counter in a super mall.
7. We don't like it when fewer check-out terminals are "on" during the busy evening time at the super mall and/or if the vendor at the terminal is gossiping instead of servicing customers!

What's happening in all of the examples above is "Performance Engineering". We are engineering a better outcome for ourselves by taking either proactive or reactive steps to known and unknown problems.
Let's elaborate on every example above a little more:

1. In example 1 above, we are managing the "capacity" of the provisions at home; by constantly "monitoring" the usage of the sugar in the container.
2. In example 2 above, we are aware of the "volumes of usage" of provisions at home; we are aware that there will be "spikes in usage" when guests arrive and "plan proactively" for such spikes of usage.
3. In example 3 above, we are concerned about "end user experience"
4. In example 4 above, we are applying "queuing principles" and "entering the fastest moving queue" in an attempt to reach the head of the queue "fast" and avoid "longer queuing delay"
5. In example 5 above, we are using the part of the road that is not blocked off for maintenance or investigation i.e. we are using the part of the road that is "available"
6. In example 6, we know how we feel when we need to wait long - so again we are aware of "queuing delay"
7. In example 7, we intuitively know that during a "peak period" in a mall, all terminals should be ON to avoid queues and promote quick service.

Well, the same principles mentioned above apply in "software performance engineering" and "network performance".
How? We'll see that in my next few blogs!

Techie Insight!

I've always felt the yearning to share technical tid-bits from experience and research.
I admire people who blog on latest technology hot topics and build opinion about upcoming advancements.

This is my dashboard to share my bit of techie insight with the world!

Welcome!
I hope to provide some good technically focussed blogs on Performance Engineering here!
Stay tuned and watch this space!