Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | RSS

Sponsor

Audible Podcast – Sign up for a FREE 30 day trial and get a FREE audiobook. I’m currently on my second listening of “Gardens of the Moon” by Steven Erikson.

In This Episode

I share a few news items from this week and then I dive into the featured topic and share some info about going with a virtual or physical server for JIRA.

Resources Mentioned

• Atlassian Summit 2015 Agenda
• Convince your boss for Summit 2015
• JIRA Requirements
• JIRA Sizing Guide
• Podcast Music – The Boss Intro (remix) – MDAJ (Me)

Social

• Twitter

---

 

Blog Version Of Podcast

Not a transcript, but a standalone blog post of the podcast if you are unable to listen. Enjoy!

Overview

In the last post we talked about going with JIRA Cloud or JIRA Server and I gave you some pros and cons with each. This post will focus on going with JIRA Server.  The reason for this is that there is much more complexity and configuration than there is with the Cloud offering. Therefore, you won’t have to think of such things, but for those that wanted the server option, they have a little bit more to choose from.

The direction you go for your server type is likely going to be based on your company policy and preference. More and more companies are opting for virtual servers as it can save them money and allows for faster startup. If your company leans to virtual then you will likely get a virtual. To attempt to go with a physical setup, you may have to provide a justification.  Here I will share some info between the two from my experience with JIRA.

Physical Server

Why Go Physical?

The primary reason you would go with a physical server is for performance. Yes, a virtual server can perform very well, but a physical server will be dedicated to the applications you install on it and only the applications you install on it. Therefore, you will not have to contend with something else using CPU, disk, and other things that your application may need.

JIRA needs two things: Fast disk, and memory.

Disk

For disk, you can simply toss a large SSD into the server for JIRA to use and it will love it.  JIRA creates an application index and stores it on the application server. This is done to minimize the calls made to the database so that there is better performance. Foregoing that network latency to request data, all JIRA data is fed from the index. This means that user searches, dashboards, filters, etc., are all being fed by the index. When an issue is created or updated, it writes it to the database and then indexes the issue so that it will display in filters and dashboards.

Due to this, JIRA is constantly reading and writing to the disk to satisfy user requests and the disk speed must be up to the task. Being on a physical server with SSD ensures that there is no contention with other servers or applications eating resources (unless you install another application on your JIRA server).

Memory

Since JIRA reads and writes a lot from its application index, it also likes to store a lot. As you grow in JIRA issues, you will grow in application memory. Some people have followed the 1gb of memory for every 100k issues.  Unfortunately, this can also be impacted by the number of plugins you have in your system as each plugin is going to eat a little bit of memory. After indexes and plugins, you now have your users to contend with and how much remaining memory is available for the application to use.

Virtual Server

Why Go Virtual?

Virtual servers allow a bit more flexibility and easier scaling. Therefore, this option is likely the default option for any IT organization.

With virtual servers, you are sharing resources with many other virtual server environments. In a well managed VM environment, this would not pose an issue to you, but if you have a VM environment that is densely packed or rather there are too many VM’s for the host, then you are going to have some problems.

Two items to keep an eye on when using a VM:

Disk

As mentioned above for the physical JIRA server, JIRA uses the disk a lot and it needs to be fast. If you are setting JIRA up on a VM, ensure that they are setting priority to resources, especially disk, to your VM. Even with that setting, what can happen is that another VM can start to consume disk IO causing longer service times for JIRA to read or write to the disk. This in turn affects the application performance.  You don’t have to be an expert at this, but it is good to know what some potential impacts are for your application.

CPU

Unlike a physical server, sometimes adding more CPU isn’t necessarily the answer. Your VM team, or internal performance team should be able to help guide you, but the best thing here is to start off with what you need and increase over time. In virtual environment I learned of such a thing as too much CPU. If you configured your VM to have 6 CPU, then it will have to wait for 6 CPU’s being available before it can process your request. If your VM had 4 CPU’s assigned to it, then it would be served faster than the 6 CPU VM as it is more likely to have 4 CPU’s available than it is for 6.

Don’t Be Scared!

I simply wanted to share out two points of comparison to a physical server that you should watch out for on a virtual server from my experience.  Virtual servers certainly have great benefit and one is that it can scale. If you find that you need more CPU or need more memory added, it can be done with the click of a button. Depending on the VM configuration, it is applied immediately or after a server restart.   This is one thing that is great about VM’s!

What About Server Size?

I said this before in my JIRA Cloud vs JIRA Server post, it is all about how you are going to use JIRA.

If you decided that physical server is the route you want to go, then you need to think about the general life of the server and your operating system of choice.  The physical server would need to be built to support your growing JIRA user base, plugins, and integrations. The JIRA Sizing guide will give you a rough estimate of what you should target. Remember, your physical server would likely need to last several years, so large SSD drives, with at least 8gb of memory and a quad-core CPU as a bare minimum and likely vastly more memory and cpu for growth.

If you decided that virtual server is your direction, then sizing JIRA won’t be so difficult, primarily because you can easily scale the VM server. I always start out the VM with 2-4gb of ram with 2gb ram allocated to JIRA, 2 cpu, and 100gb disk. As you grow in issues, plugins and users, you will scale JIRA up by increasing memory, cpu, and disk as needed.

Summary

It is all about your use case. Before you set out to build your JIRA environment, you need to sit down and understand how you will use the application, and who your audience is. If you are converting from other tools to JIRA as the replacement, then understand the use of that tool. How many users? How many requests created per month? This can help you identify the potential growth of JIRA and better handle the onslaught of users once they find out how awesome it is.