Looking for another culprit

Often, a performance problem occurs at production level, and the customer alerts you that it is not working as it used to when the software was being tested. Performance problems might occur because the application was not planned to work in the real world with a high number of users and ever-increasing amounts of data.

But if the application interacts with other applications, the first thing to do is to check if the bottlenecks are located on those interactions. For instance, if you use a database server or any kind of external service that needs to be communicated over the network, then it is possible that performance issues are due to service misuse (for example, heavy SQL queries) or many serial network connections that could be easily parallelized.

The physical links between applications should also be considered. Maybe the network link between your application server and another server in the intranet is becoming really slow due to a misconfiguration or congestion.

Good and up-to-date architecture design documentation that contains diagrams of all interactions and the nature of each link is invaluable in providing the overall picture of the whole system. And that picture is essential when trying to resolve performance issues that occur on the boundaries of many networked components.

If your application uses third-party servers of resources, every interaction should be audited to make sure that the bottleneck is not located there.