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,

  Привет!  На связи Гончик, любитель APM (application performance monitoring) инструментов, в частности Glowroot .  Сегодня расскажу о том, как за кратчайшее время найти узкие места в Confluence On-Prem на основе одной промышленной инсталляции.  Мы столкнулись с ситуацией, когда большое количество людей одновременно ломится в базу знаний на Confluence On-Prem (во время сдачи аттестации), и конфлюенс умирает на какое-то время. Сразу подумали, что проблема именно в одновременном количестве посетителей и сразу можно затюнить JVM, но оказалось, что не все так однозначно. Ниже расскажу, как мы нашли реальную причину тормозов и как с ней справились. Основная задача: провести аудит и на его основе добиться улучшения производительности, особенно в моменты большого количества активных пользователей в системе.  Конечно, в первую очередь были проверены ап паратные ресурсы, конфигурации ОС, где никаких проблем не выявлено.  Однако, отсутствовали access логи nginx, поскольку конфигурацией была откл

  Today, I would like to collaborate with the community about  the real usage of Insight for Jira in world instances and provide my feedback. As we know on Cloud, Insight for Jira has a limit of  400k objects for Enterprise subscription , 60k for other situations on the Cloud. So for the on-premises releases Insight for Jira has not any limitation, except  heap size requirement.   Objects in Insight JVM memory ~10.000 4Gb ~100.000 8Gb ~500.000 16Gb ~1.000.000 32Gb ~2.000.000 64Gb ~5.000.000 128Gb Note the next info: remember to always test the memory consumption in a test environment for a huge data set, because it's not always the number of objects, but the content of the object attributes as well at play.  i.e. one of my instance has  Jira/JSD/JSM version:  8.13.9 (3 nodes in DC) Insight version:  8.7.9 Java version:  11.0.11+9 GC Strategy:  G1GC   Heap Size:  38 GB Count of Objects:  1.6 mln objects Count of Units (Attribute values):  49 mln units At the moment, it works well, b

  Hello,  Today I would like to share a small story about the performance improvement of Confluence for one large company. They used that installation for more than 3.2k requests per minute based on the daily stats from frontend reverse proxy logs. The architecture of that is quite simple based on the reverse proxy (nginx),  Confluence app (tomcat), PostgreSQL as RDMS.  All those services work on CentOS 7.  On Confluence in (Tomcat logs and application logs), nothing informative logs were.  So in dmesg I found quite simple information about SYN flood on the Confluence app side. Of course, it’s quite crazy to see that situation in an organisation in  2020 ’s. # dmesg | tail [  734.711105] systemd[1]: Started Journal Service. [1140053.637848] FS-Cache: Loaded [1140053.662442] FS-Cache: Netfs 'cifs' registered for caching [1140053.662535] Key type cifs.spnego registered [1140053.662538] Key type cifs.idmap registered [1140053.662889] Unable to determine destination address. [11400

  Hi!  Today I would like to share just one of the customisations related to the UI. Of course, it's a small AJS, AUI trick :)   Still, most of my Jira instances are DC and Server.  And quite often request to see the standard Log work button on the next panel.  instead of here   That’s easy to set via console log: snippet: const logButton = '<a id="new-log-work" title="Log work" class="aui-button toolbar-trigger issueaction-log-work" href="/secure/CreateWorklog!default.jspa?id='+JIRA.Issue.getIssueId()+'" resolved=""><span class="trigger-label">Log Work</span></a>'; AJS.$('#opsbar-opsbar-operations').append(logButton);    We can set that change into an Announcement  banner  or use some app,  like JSincluder.  You can in marketplace or in github.   Hope it helps. Cheers, Gonchik