Change is required. Atlassian engineer's blog

  Gonchik, a lover of APM (application performance monitoring) tools, in particular Glowroot, is in touch. This is the second story related to observing Confluence with Glowroot. (First is   here ) Often, analysis is helped by looking for patterns such as time of complaints and correlation with application response time graphs, especially in percentiles, which gives an understanding and clarity of what is happening with a small volume of requests. By switching to slow traces mode in the Glowroot dashboard, you can take a closer look at the behavior of the system.   and also in the specified screenshot, I observed the following behavior:   All this prompted me to view the schedule of batch operations, for example, the time when the backup process was started. First of all, I checked in the web interface ({CONFLUENCE_URL} /admin/scheduledjobs/viewscheduledjobs.action) and disabled backups in xml at the application level. You can also see the launch history, and, in principle, understand

  Hey! Gonchik, a lover of APM (application performance monitoring) tools, in particular Glowroot, is in touch. Today I will tell you how to find bottlenecks in Confluence On-Prem in the shortest possible time based on one industrial installation. We are faced with a situation where a large number of people simultaneously break into the knowledge base on Confluence On-Prem (during the certification), and the Confluence dies for some time. We immediately thought that the problem is precisely in the simultaneous number of visitors and we can immediately tweak the JVM, but it turned out that not everything is so simple. Below I will tell you how we found the real cause of the brakes and how we dealt with it. The main task: to conduct an audit and, on its basis, achieve performance improvements, especially in times of a large number of active users in the system. Of course, first of all, the hardware resources and OS configurations were checked, where no problems were identified. However,