Before an application enters the development phase, there is a thorough discussion on what the application is supposed to do, how it will do it, and what kind of third-party components the application will need to interact with. Once all of this is finalized, the application enters the development phase, where the developers are responsible for building the application in such a way that the tasks to be performed by the application can be achieved in the most efficient manner possible. This efficiency is usually measured in terms of how much time an application takes to complete a provided task and how many resources it uses while working on that task.
When the application is deployed into production, the real test of the application begins. Most of the time, if the work being done by the application is the same as was defined during the requirements-gathering and design phases, the application usually performs well and provides an adequate scalability. But as developers, we know this is seldom the case.
Most of the time, workloads in production differ significantly from what was conceptualized during the design phase. Usually the data that the application is dealing with grows over time as the application is used in production and can become orders of magnitude larger than what was initially conceived during the application development phase. Another factor that may impact the performance are the side-effects exerted by the production environment on the application such as poor execution performance of certain workloads.
The result is that some of the workloads are efficient while the performance of others suffers. This deviation can range from very small and insignificant which may easily get unnoticed to considerably significant that may disrupt the regular workflow of the organization.
Once these kinds of issues are identified, developers work to optimize them over time and improve the efficiency of completing a provided workload. This is perfectly normal in any enterprise or consumer environment, because some of the issues can only be identified when the application is subject to varied workloads in production, which differ significantly from the ones that were tested during the internal testing phases.
To fix these performance bottlenecks in workloads, you should have an idea of why and where a particular bottleneck is happening, and then a developer can work to fix the bottleneck or to improve it so that its impact is reduced. So, let's take a look at some of the possible factors that might cause performance issues, and then we'll move to trying to understand how we can figure out the places where these performance issues are happening and how can we possibly fix them.