Software is often delivered in different ways to different set of users. Some get it via the web, others access it through the cloud, and some get it on specific device like a smartphone or personal computer. All users have different expectations of how they use the software and it has impact on how they perceive performance of the software. From a product angle, a software meets the performance expectations of the user if it delivers the function/feature promised within the agreed time. From an engineering perspective, a software is seen as performant if it makes the most use of the resources (cpu/memory/nodes/network). If the performance is seen as throughput, then it is the ability of the software to deliver maximum throughput for a given set of resources. Performance shouldn’t be confused with scalability - ability to deploy the software at scale, or availability - defines the uptime of the software. In this series, we are going to restrict ourselves to the engineer's read on the software performance.

Like any other gauge, performance also needs a gauge to measure it. The right gauge for a software depends on how it is deployed:Webservice - performance is measured as it's latency, resource usage, throughput: TPS - transactions per second without breaching any of the sla (service level agreement)

Desktop - performance is measured as the time taken to process the core purpose of the software. (E.g.: Time to export a 1min of a movie, Time to run a image operation)

Mobile - performance is measured as the time taken to start up, battery consumed per specific operation/task, time taken to complete the core purpose of the app

Data Server - performance is measured as queries per second, transactions per second, i/o per second

While a software needs to meet the SLAs on non-functional metrics (apart from functional ones) to be certified as "good for consumption", Performance Engineering is about meeting the performance sla with efficiency - make the most use of the resources the software runs on (thereby saving costs). Typically, the efficiency part isn't taken care as part of software development cycle, resulting in an inefficient product that meets the SLAs (consumes more resources or isn't capable of making most of the resources). Performance Engineering takes lime light when firms try to cut infrastructure costs and focus shifts towards achieving the SLAs with less resources or relaxing the SLAs or could be a mix of both. Performance Engineering if employed properly results in software that makes most out of the resources it runs on (bigger bang for the buck).

In this Performance Engineering Series, I am going share details on capturing the performance metric and also about building systems efficiently in order to maximize the value of that metric with minimal resources. Here is a gist on what is being covered as part of this series: