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!