making a difference with 'performance'
So what is performance ? Really, what is it ?
After spending almost 12 years in the industry, I tend to reflect on our notion of performance. I have talked to many people over these years including peers, colleagues, customers and industry experts and have a very different view from different people. Sometime we (mis)use or ab(use) it knowingly or unknowingly. So I thought I would spend some time answering this very basic and fundamental idea on 'performance'.
'Performance' is a much larger concept that it is meant to be. When we put that in the context of our 'technology/software systems', it has a meaning for each components/layers. On the face of it, 'Performance ' is the measure (not the perception) of how fast a system responds to a request. Quite a simple concept, isn't it ?
Let's drill down a bit further.
When we talk about systems, it comprises of primarily three elements - a. Application software b. The infrastructure on which this piece of software will be run c. Underlying architecture that binds these two pieces together. Let's take some of the complex elements out for the sake of simplicity.
Now think again. What is 'Performance' ?
This time let's try to answer in a bit different way. Performance is the outcome of how the above three elements interacts with each other to produce a 'fast' system. The final outcome will be the resultant of the 'performance' of each individual systems. Each of them will grossly influence on how the 'system behaves' under load. Observe the word 'load'. 'Performance' is the outcome of 'load' injected into the system. And load can be injected through various means - it may be 'user volumes (i.e, multiple users are accessing the systems), frequency of occurrence ( i.e, transaction frequency - how frequently you are hitting the servers), payload ( with what details you are hitting the server and how much are you demanding of it).
Now a little more into the world of performance. What measures are in place to decide 'performance' of a system ?
The measurement of performance is not just how fast the system responds but can be extended to few other aspects that collectively decides the overall 'performance ' of the solution. The other two areas that will be of importance is the 'Throughput' and ' Success rate'.There is a direct correlation between the 'faster response' and the 'throughput'. The less times it takes to finish a task (transaction), the more number of tasks could be completed in a span of time. Also a faster response is meaningless unless it becomes a true and successful response. The better success rate you achieve under a heavy load, the more performant your system is.
Apart from these, there will be other attributes that drives the end user performance including a number of client side factors. Performance of browsers, client side devices, terminals etc. impacts your end results and should be counted towards your end user experience. The goal of performance is not just to ensure that your software and infrastructures are optimised, it is equally important that you optimise the access channels and your application should be adaptive enough to be 'performant' across a diverse range of channels. And the discussion can go on and on...
Next time when you hear the word 'performance', may be think a little more ! What they actually meant ?
@Aravind - May be that's why I mentioned that the discussion can go on and on :-) On a serious note, 'Performance' itself doesn't define a single thing ( although its measurable by various means), it is the resultant of so many other things. Load is just one of them as you rightly mentioned. To your point, to define/measure the 'performance', you do not necessarily need another benchmark to compare. 'Performance' can still be relevant when you know what to 'expect'. Comparing to benchmark is probably more relevant when we talk about 'comparative performance'. I wish to cover that may be in another post.
Love this writing