data center

#All #Document management#Reporting#Analytics#Integration#monday#How To#AI#News#Confluence Tutorial#Confluence#Jira#Bitbucket#Case Study#Learning Management#Collaboration#Project management#Task Management

Atlassian Applications: Performance Issues to Consider

May 2, 2019
#How To#News
10 min

A great number of companies worldwide are using Atlassian applications every day. One of the most critical points is performance of Atlassian applications. It is important to keep your Jira, Confluence, or Bitbucket as robust as possible. Low performance and even unpredictable freezes can ruin the user experience and lead to significant decrease in performance of your employees. The growing frustration and dissatisfaction with work results are just additional attributes of this all.

Common Dogmas

Performance of Atlassian applications depends on the multiple factors, as follows:

  • Hardware
  • Application
  • Data amount
  • Configuration and settings

A slow application server will cause temporary lags, freezes, and long response time when the application operates under the load.

The version of the application may also impact the overall performance. The Atlassian development team is actively working on performance of applications, and every new release improves the performance of critical user interfaces.

Data amount impacts performance of the Atlassian application too. The more data you have, the slower response of the application you will have. Here you need to understand that larger data amounts require faster hardware components, so a common server will have serious performance issues with processing one million of issues or pages.

Configuration and settings of the Atlassian application and environment where it operates are additional things to keep in mind. Out-of-box settings may be inappropriate, so here you need to run some experiments to find the optimum.

Cloud Atlassian Applications

Unfortunately, you cannot adjust performance of the Cloud Atlassian applications anyhow. If you experience performance issues with your Cloud application, try to contact the Atlassian team.

The other thing to consider is the location where Atlassian hosts the data center with your Cloud application instance. If it is quite far from you, you can ask the Atlassian team to move your Cloud instance to the data center which is closer to you.

Server Atlassian Applications

Performance of the server Atlassian applications depends on different factors, so it is better to adjust issues from different spheres one by one. This allows you to determine what positively impacts the performance, and what does not impact at all.

Hardware Components

First of all, install more productive hardware peripherals, more memory, faster CPU, and SSD drives running in a RAID mode.

The SSD drive impacts the I/O operations of your Atlassian application. The traditional HDD drive does not provide the sufficient performance for resource-intensive applications. Use SSD drives to store your data, including the database.

Then you need to separate the database server and the application server from each other. Running them both on the same physical server impacts the performance of the Atlassian application.

When you are using a VPS (in Amazon AWS or anything else) for running the Atlassian application, add more memory and increase the number of CPU cores, and then increase the amount of heap memory for the application. Resources of the start-level VPS instance will be insufficient for operation of the Atlassian application being used by thousands of users.

If after these manipulations the performance remains at the same level, you need to consider additional points. First of all, take a look at the best practices from Atlassian. Use the logging and profiling to identify the bottlenecks and address them.

Software Optimizations

Adjust the number of HTTP and database connections to the application. The insufficient, as well as the great number of connections, may lead to problems with the request servicing time. You need to determine the optimal number of these connections for your instance as it depends on quite many factors. Enable the HTTP response compression, this option should be enabled in Bitbucket, by default.

Install the latest application updates and upgrades. For example, Jira 8 is much faster than Jira 7, the same also applies to the latest versions of Confluence.

Archive the old Jira projects that your team no longer use. This feature is implemented for Jira Data Center, but you can try to do the same in Jira Server. Get rid of unused custom fields and apply the comprehensive administration policy.

The storing of indexes on the RAM disk can significantly improve the performance of the Atlassian application even on the server with SSD drives. The only disadvantage of this approach is that restart of the server will ruin all indexes and you will have to re-run indexation. It is recommended to have an exact copy of the production server where you can do all these experiments and see whether there is any effect from them. Only then adjust the production server.

If you are using Confluence, you need to remember about Synchrony service which is used for collaborative editing. It also has its own memory settings, so if you notice any issues with it, add some memory.

In case of Bitbucket you need to acknowledge that it creates git-processes on the host. During the peak load these git-processes may require much more memory than Bitbucket itself needs. This mainly depends on the development workflows you use and size of repositories.

You can also limit the load per user through the reverse proxy. This can be used in situations when some user account generates too many requests which slows down the Atlassian application.

Automation, Monitoring, and Antivirus

Adjust the schedule of running all automations, data exports, imports, and backups. Limit their load and execute them during the inactive hours. In case of distributed teams this can become a real challenge.

Use the monitoring with different metrics to identify the existing and possible performance issues. Evaluate metrics on a regular basis and set up notifications for critical load values.

Antivirus checkups can negatively impact performance of the Atlassian application. Run the full system scan during the inactive time or in hours of the lowest load. The full system check can decrease the I/O operations during the check time.

If after all these efforts, the performance of the Atlassian application remains the same, it’s time to move to Data Center.

Data Center

Data Center operates as a cluster of application nodes. All the requests are processed by the load balancer which further routes requests to the appropriate node.

You can have as many nodes as you need. Their number is not limited anyhow by the Atlassian license. But usually, in some situations there is no sense in adding more nodes. The shared home directory should be single and you need to store it on the fast drive, preferably SSD. The same applies to the database. If nodes operate on the same physical server, the scaling effect will be hardly noticeable.

If you see the positive impact from adding nodes, you can automate this process. This approach can be very efficient when you use VPS for running the Atlassian application. You can automatically start additional nodes on a new VPS machine during the peak load, and suspend them during the inactivity period. This way you will preserve the high level of performance and will save money on VPS usage as you will use it temporarily.

The other thing which you can implement is integration of CDN. It can be integrated with Server and Data Center Atlassian applications. All attachments and media assets can be loaded through CDN. This will decrease the load on the application and will improve its response time.

Not sure what to start from?

As you may notice performance of Atlassian applications depends on quite many things. It can become a real challenge to identify the potential bottlenecks without having sufficient experience and expertise in the Atlassian platform. But you can always contact us and get a free consultation.

Just drop an email at tech-support@stiltsoft.com and we will contact you shortly.

Related posts
    #All #Document management#Reporting#Analytics#Integration#monday#How To#AI#News#Confluence Tutorial#Confluence#Jira#Bitbucket#Case Study#Learning Management#Collaboration#Project management#Task Management

    Awesome Graphs for Bitbucket: Exclude Files from Lines of Code Statistics

    March 22, 2019
    #How To#Bitbucket
    9 min

    Awesome Graphs for Bitbucket is an app visualizing statistics of Git repositories in terms of commits, pull requests, and lines of code. The Contributors graph, and the Code Frequency graph show how many lines of code were added and deleted in the repository in general and by each developer. 

    Sometimes lines of code statistics doesn’t represent correctly the actual effort and value that developers bring to the repository. For example, if a new library was added, it will bring hundreds of new lines while a task itself was easy to do and took half an hour.

    To make your data more precise and informative, there’s a feature in Awesome Graphs that allows the exclusion of files from lines of code (LOC) statistics.

    Why Exclude Files from LOC Stats

    This feature will be helpful for users, who:

    • Include source code from third-party libraries, and don’t want to count it towards individual code contributions.
    • Want automated code generated files not to be included into LOC statistics. 
    • Version a lot of configuration in very large xml files, and don’t want to count their updates as additions of thousands of LOC.
    • Want to include in LOC statistics only files with selected extensions (i.e. c, cpp, h).
    • Want to count in LOC statistics only files from the selected directory (i.e. src).

    How it works

    Repository administrators can add patterns in a gitignore format telling what files have to be excluded from LOC statistics of a repository.  

    bitbucket repository settings

    It is possible to exclude:

    • particular files
    • all files with selected extensions
    • all files from selected directories
    • everything except files with selected extensions
    • everything except files from selected directories

    When an administrator adds or modifies patterns, Awesome Graphs re-indexes the repository and displays graphs with new LOC statistics.

    Benefits Examples

    You can see examples of this feature usage in public repositories.

    Statistics for the main directory of a repository

    Let’s view the Contributors graph for the jquery repository. It shows additions of LOC in the whole repository.

    contributors bitbucket

    The repository exists since 2006, but according to the graph there was no significant activity there till 2014.

    It would be great to make the graph more informative and calculate LOC statistics only for the directory containing the main source code – src. We exclude from statistics all files except files from this directory and get a new graph showing the most important activity happened in the key folder of the repository. 

    contributors graph bitbucket

    Exclusion of files helped to get new insights:

    • There was intensive activity in 2006-2008, 2011, and 2014.
    • There was no significant activity after 2016.
    • Only two of top four contributors to the repository are also in the top four contributors to main source code.

    In the first graph there were peaks of activity showing additions of 50K and even 250K lines of code per week. In the second graph the largest peak shows addition of 25K lines of code, others – about 5K. This data represents the real work of developers more accurately.

    Exclusion of third-party libraries from statistics

    Let’s view the  graph for the kubernetes repository.

    Bitbucket Code Frequency

    There are two peaks of activity: addition and deletion of more than 300K lines of code. They represent not actual work, but operations with third party libraries. Huge peaks of additions and deletions caused a large scale of Y axis. Due to this all other activity seems to be non-significant.

    Let’s exclude from lines of code statistics files from the directory third_party.

    The graph has become more accurate. Peak values disappeared. The scale of Y axis decreased allowing to get a better understanding of the activity in the repository.

    Get more informative LOC statistics

    Using Awesome Graphs for Bitbucket, you can enrich your commits, lines of code reporting with the REST API the app provides. For example, you can easily count each pull request size to decide whether it needs to be decreased. Read more about it in our blog post.

    Try the app for free discover more benefits and unleash the potential of your teams.

    Related posts
      #All #Document management#Reporting#Analytics#Integration#monday#How To#AI#News#Confluence Tutorial#Confluence#Jira#Bitbucket#Case Study#Learning Management#Collaboration#Project management#Task Management

      Data Center Approval Procedure for Atlassian App Vendors

      January 8, 2019
      #Jira#Bitbucket#How To#Confluence
      8 min

      Atlassian delivers a variety of applications for planning activities, managing projects and products, storing source code, and building solutions to small companies and large enterprises. Like no other companies, Atlassian team understands how unpredictable downtime or performance downgrade may cause operation instability even in the company with refined processes and procedures.

      To avoid occurrence of such issues in operation with their applications, Atlassian initiated the Data Center approval program for apps distributed on the Atlassian Marketplace. This program was designed to ensure that apps for Data Center are developed with highly available, clustered environments in mind. Each app undergoes a testing and validation process run by Atlassian in cooperation with a Marketplace vendor. Apps that successfully pass this procedure are proven to perform reliably and consistently in large-scale Data Center environments.

      Developing App for Atlassian Data Center Application

      Marketplace vendors that want their apps to be compatible with Atlassian Data Center applications need to undergo the approval process. It includes the following:

      • Filling out a Technical Readiness Checklist for the app
      • Testing app impact on application endpoints
      • Scale testing of the app and its impact on the Atlassian application
      • Support and issue escalation details

      All these items require significant input from the vendor team and preparation of the large-scale environment for testing. The vendor team needs to identify all the integration points where the app interacts with the Atlassian application and test their performance.

      Technical Readiness Checklist

      This is a detailed questionnaire with more than 150 questions detailing the app operation in the Data Center environment. It is comprised of the 10 major sections that cover all the crucial aspects of the app processes and its impact on the Atlassian ecosystem.

      It requires specification of information about data caching and its distribution across nodes, database transactions, cluster locking for running long-term operations, event handling, scheduled tasks, resource usage, security, and other things that may impact the Atlassian application.

      Testing Application Endpoints

      The vendor needs to run a series of tests to verify that the app does not have great impact on the native application REST endpoints after the app installation. This is required to ensure that the app cannot cause the endpoint slowdown or failure under the high load. If your app does not interact with any application endpoints, this testing can be skipped.

      Scale Testing

      Every app needs to be tested in the one-, two-, and four-node environment under the high load. This load testing allows you to identify problems if your app greatly impacts performance of an Atlassian application. Testing is performed in two runs: with the app enabled and with the app disabled. Here the vendor can get great insights on the performance of the app under the load and identify points that can be accelerated.

      Support Escalation Details

      Here the vendor specifies how and who the Atlassian team may contact in case of an emergency case. Every vendor needs to have a dedicated contact channel to provide support for enterprise customers with Data Center deployments.

      Making our apps Data Center approved

      We at StiltSoft have already four apps approved for usage with Atlassian Data Center applications. Here they are:

      • Awesome Graphs for Bitbucket – app to visualize and analyze performance of individual developers and evolvement of project repositories over time.
      • Table Filter and Charts for Confluence – app to manage table data, filter data against multiple criteria, aggregate it in pivot tables, and visualize this data with all sorts of charts and graphs.
      • Smart Attachments for Jira – app to organize retention of attachments in dedicated categories within issues, set access restrictions, and run automated operations or file validations during workflow transitions.
      • Handy Macros for Confluence – a set of tools and augmentations to simplify real-time interactions with content in Confluence. It bundles the switchable status sets, image and video carousels, task reminders and inline task lists.

      All these apps have passed the Data Center approval and proved to be reliable and stable solutions under heavy load.  For all these apps you can install the Data Center compatible version on the Atlassian Marketplace. In the interface of the app listing page, you can select the appropriate hosting option, as follows:

      Don’t wait and try these apps in your Data Center environment.

      Related posts
        #All #Document management#Reporting#Analytics#Integration#monday#How To#AI#News#Confluence Tutorial#Confluence#Jira#Bitbucket#Case Study#Learning Management#Collaboration#Project management#Task Management

        How and Why to Migrate between Atlassian Server, Cloud and Data Center Applications

        December 18, 2018
        #How To#Confluence#Jira#Bitbucket
        18 min

        Atlassian applications are offered in the three different types of deployments:

        Cloud. Atlassian deploys and maintains applications providing you with quick access to them. This way you are always up-to-date with all recent features. With a 7-day trial period and subscription-based pricing, Atlassian provides you with a great chance to try and adopt Atlassian software with minimal efforts.

        Server. A lot of companies use this classic deployment option because it allows them receive full control over the application. A perpetual license and access to more than 3000 apps for Server products instead of 1000+ apps for Cloud tools make this option the most popular one at the moment. Server versions have a 30-day trial period.

        Data Center. One of the benefits of using Data Center is that customers with high demands get enterprise-level clustered instances. High availability, scalability, enterprise features, and approved apps make Data Center a great choice for large companies looking to expand and scale fast. With a subscription-based pricing model, Data Center comes with a 30-day trial period.

        What to choose?

        The most suitable type of deployment depends on the size and structure of your enterprise, as well as it depends on the type of data that you use, security requirements, and more. Let’s compare these three options to help you choose the one that best suits your needs.

        Cloud Server Data Center
        Unlimited users (error) 5000 users limit (tick) (tick)
        Administration-free (tick) (error) (error)
        Quick deployment (tick) (error) (error)
        Automatic updates (tick) (error) (error)
        Custom domains
        (confluence.company.com)        		 (error)
        (atlassian.net domain is used)        		 (tick) (tick)
        Choice from supported databases (error) (tick) (tick)
        Direct access to the database (error) (tick) (tick)
        Perpetual license (error) (tick) (error)
        Enterprise features
        (see details for Jira, Confluence and Bitbucket)        		 (error) (error) (tick)
        High availability (error) (error) (tick)
        Scaling (error) (error) (tick)

        Atlassian Marketplace apps

        		 (star)(star) (star)(star)(star) (star)

        Reasons to migrate between deployments

        Cloud to Server

        We think that this migration is the most popular one. However, companies sometimes prefer to migrate from Server to Cloud.

        Fast-growing companies that start their Atlassian experience from Cloud can quickly get close to their storage or license user limits. In this case their business processes become more complex and they need customizations that Cloud can’t provide them with. Some companies may also join other companies, and each of them needs to get access to both companies’ data. Also, companies may have complex processes that can be significantly simplified by installing apps from the Marketplace that aren’t compatible with Cloud deployment. The best way to deal with these issues is migrating to Server deployment and possibly merging instances into one.

        Sometimes companies split into two or more separate business units. Some of them don’t need strict security or complex processes as well as a lot of users and customizations. In these cases it looks more logical to decrease administration burden by moving to Cloud.

        Server to Data Center

        Another example is dynamically growing companies that actively use the wide set of features. After creating tons of projects and issues in Jira, or gigabytes of repositories in Bitbucket, or hundreds of spaces in Confluence their software slows down. It’s logical but it can adversely affect the quality of their work. The obvious way to overcome these problems is moving to Data Center. Using enterprise features (like project archiving in Jira), customers can decrease the number of issues. Also, there are other ways to improve performance and stability that are only available in clustered software (like separate application nodes for reporting and automation purposes).

        Other migrations

        There are no strict rules for migrations (but each case should be considered independently). It’s even possible to migrate from Cloud to Data Center and from Data Center to Cloud. That means that you can always stay with Atlassian software, regardless of the size of your company.

        How to migrate between deployments with minimal impact on your business

        Approaches to migrations differ depending on the size of your company, a number of business processes and their complexity, and other factors. You need to choose the right one.

        If your company (as well as an instance of Atlassian software) is small, migration usually looks simple. Mostly, these are migrations from Cloud to Server. Usually, you can perform such migrations yourself, the process is well-documented and pretty simple. You can also ask your technical folks to do that as the process doesn’t require any specific skills. At the same time, there can be some obstacles that make this kind of migration more complex.

        If the business is big, there are usually large amounts of data stored in your Atlassian software. These companies mostly migrate from Server to Data Center. This kind of migration is complex and requires a deep understanding of requirements and limitations to choose the right implementation. You need a team of well-trained professionals and a person whose role is to coordinate the team to get your applications migrated. Ideally, you should have an experienced Atlassian Certified specialist in your team to avoid the obstacles (the number of obstacles increases comparing to the previous case). Also, the process of migration and its result should be thoroughly tested to make sure the move went smoothly.

        The alternative way is to get help from Atlassian Solution Partner company.


        Atlassian Partners have a deep understanding of the ecosystem, they know every aspect of Atlassian software and typical challenges you may face during migrations. The most difficult thing in migration is to choose the right options from a wide variety of available options keeping in mind the unique needs of companies on a short-term and on a long-term basis. Also, Atlassian Partner competencies are confirmed by Atlassian Certifications and Atlassian Accreditations held by team members (it’s a part of the Partner Program requirements). Atlassian Solution Partners can help you accurately evaluate what exactly you need and get some recommendations on migration process. They can also support you during your migration and help you in resolving issues after that.

        If you have any questions about migration or need some help in choosing the most suitable option, feel free to contact us. Ask us any questions for free!

        Related posts