May 27, 2021 at 8:14 pm
Comments posted to this topic are about the item Top SQL Queries to Safeguard JIRA
June 30, 2021 at 3:50 pm
My opinion is that if a product has so many performance issues, perhaps it's better to find a different product. Atlassian is obviously aware of the performance problems, especially because they require a special isolation level as a part of the installation of the product. Wouldn't it be a whole lot of fun if it turned out that was the cause of the performance issues? 😀
Seriously, though. It's not like this product is new or anything. Why are there any performance issues and why do the end users end up having to fix Atlassian's problems with data? If any of us did such a thing, we'd be drummed out of the business.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 30, 2021 at 4:04 pm
The cynical answer is that Atlassian is gently encouraging people to use their cloud services instead of on prem.
June 30, 2021 at 5:24 pm
Heh... and why would anyone in their right mind think that's going to be any better. Notice I didn't put a question mark after that statement. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
July 2, 2021 at 10:20 pm
Below is my opinion, I do not work for Jira and have no knowledge of their back-end magic.
I think one of the main reasons that you would want to do that overhead with Jira running on a SQL Server backend is that Jira is not the "administrator" of the database; your DBA is. It creates the objects it needs and runs with it. End users (actual end users PLUS Jira Administrators) can then create a mess in the system and cause a bunch of performance issues.
We have been running the product for a while now (since 2016) with minimal performance issues. The performance issues we did hit were network related OR due to 3rd party addons in Jira than anything else. Our Jira Admins have all had training done and keep up on best practices with Jira to ensure things flow smoothly. The same work is done by the administrator of ANY system. If you hired a SQL Server DBA, you would hope that they have some knowledge on how to administer all currently supported SQL Versions such as SQL Server 2019. But if that DBA has 20 years experience at XYZ Inc and they are running SQL Server 7.5 still, that new DBA to your team is going to offer a LOT of bad practices and likely cause performance issues on the system.
I find most 3rd party tools that support multiple database platforms end up having odd tweaks or changes to "default" setting, such as the isolation level; it isn't isolated to Jira.
Atlassian is also not retiring ALL on-premise versions of their tools - Data Center is still around and is likely not going away anytime soon.
My understanding is the main reason for retiring the "Server" model of Jira was that it was the only version that had a 1-time fee for the license. Your renewal costs were just so you could install the latest version. If you decided to stop paying, you could still use Jira with no limitations except for having no support and having no upgrades you could install.
To add to what Jeff said though, if the application administrator does a poor job of maintaining the tool, OR if the company who is using it is trying to use it for something it was never designed to do, it will have performance issues. Imagine throwing a C# developer who has never written a SQL query in their life and asking them to update data in the database using ONLY TSQL. There is a HIGH chance that they are going to develop a row-based solution with a loop of some flavor. Their query will work and may even run pretty quickly initially while the number of rows is small, but over time as row counts rise it will have performance issues.
A Jira administrator falls into a similar bucket as that. You throw a DBA in as a Jira admin and don't train them on best practices and how to keep peak performance, you are going to have performance issues.
Like any system, maintenance is required and you need a good, smart administrator on the system so they know what to look for and what to manage to help improve performance. Plus you need a good administrator who can know where to look for performance problems. If SQL Server starts performing a bit sluggish, a good DBA will know that it isn't ONLY on the SQL side that you need to investigate. It is a good starting point, but depending on the symptoms (single query slow vs all queries slow), it could be an issue at the OS level, or even a hardware issue. Same thing applies to Jira (and ANY vendor-supplied tool). I've seen our ERP tool get laggy and it was a database related issue. I've seen our service desk application get laggy and it was due to the hardware firewall. I've had poor performance on SSRS and it turned out to be a DNS issue.
Performance issues for a single company/user on a tool used by a LOT of companies usually means one of three things. Either you misconfigured it, you are using it wrong, or you are not doing proper maintenance on the tool.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
July 3, 2021 at 9:52 pm
@ Brian...
I agree that a good DBA is necessary to prevent performance from tanking on 3rd party databases but, I'm not sure I'm so happy with Jira as a lot of folks (like you) seem to be. Any time an application requires a snapshot isolation to be supported, it does raise some serious concerns about the product. It's kind of like when a product says that it MUST log in as the "SA" login... ya just gotta know there's some fly poop in the pepper somewhere in that. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
July 4, 2021 at 2:25 am
I feel you there. But if that is what it takes to make the tool then that's what it takes.
Also, I wouldn't say I like Jira... it has its purpose, but I don't feel I am the right person for using it. And administering it is a pain in the butt. A problem with it can be from any one of a million different things and I have yet to find a single "good" approach to troubleshooting. And their permission schemes are something to be desired. Confluence is definitely worse to administer permissions, but Jira is a pain in the butt.
Where the tool is good is for project control for teams, especially remote teams. It is easy to track work being done and easy to evaluate the work of the team. That being said, it adds a lot of overhead to tasks that don't really need it. And, as I said, administering it is a huge pain in the butt. Thankfully for me, we are using PostgreSQL for the back end database AND running it on the same VM as Jira. As it isn't a SQL Server back end (with our setup), AND I have no SSH access to the VM, that part of the administration is out of my hands!
I do agree with you though about sa... no app should require sa except for someone who needs to do system administration. As for needing snapshot isolation, I have found that in most cases when the app recommends that, it isn't a hard requirement. It is just a setting recommendation. In general though, I don't have a big problem with setting things like that up IF it makes sense for the application AND it isn't causing any serious issues on the system (mostly around disk space).
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
July 5, 2021 at 3:02 pm
I wasn't involved much in the installation of the database for the Jira application except that I was told by the vendor that Atlassian won't even talk to someone with performance issues on the product unless snapshot isolation is enabled per the product spec.
While I don't see it as causing any serious issues, I'll state again that I find that applications that require snapshot isolation to get performance to be annoying at best. It's not that I have a whole lot against the use of snapshot isolation. I've just found that people use it as an excuse for not writing quality code. It's a lot like people that try to kill performance problems with iron. Sometimes it works but, if your multirow code won't go parallel because of the way it's written, extra iron isn't going to help. Of course, going parallel can actually cost you a whole lot, as well. There is no "panacea" of performance when it comes to such things. Performance is "in the code... or not".
--Jeff Moden
Change is inevitable... Change for the better is not.
July 5, 2021 at 3:19 pm
And all this makes me wonder what value you're actually getting with on premise Jira vs just using the hosted option.
July 5, 2021 at 3:53 pm
And all this makes me wonder what value you're actually getting with on premise Jira vs just using the hosted option.
That's a good question and I don't have an answer. Maybe they finally considered hidden costs and recursive billing for things that should have been a 1 time cost? Some of the stuff reminds me of the old "unlisted phone" charges... people paid $4.95USD per month for that "feature" but the phone book was only published once per year. It should have been a "once per lifetime" charge.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 5, 2021 at 4:10 pm
On premise means we can limit access a lot better and we have control of the backups and the raw data (filesystem and database). Plus on premise (Server) is cheaper than cloud and some addons we use don't have cloud options.
Once it is in the cloud, we lose a lot of control. This is true for all cloud based tools. If we wanted to do backups nightly with VM snapshots hourly, we can do that. If we only want to do weekly backups and no snapshots, that's fine too. We can do whatever we are comfortable with. PLUS when doing application upgrades, we can plan them and test them on our test/dev systems prior to doing it on live AND we can ensure that test and live are perfect clones of each other prior to doing the upgrade too. With cloud systems, we are trusting the vendor to provide the test and live environments to be identical and it may not be the case which COULD cause upgrade issues.
My preference is always on premise as I like having control of the systems I am managing. I know how things are configured or know who to ask for both the server and application side. If our auditors (for example) wanted to know how backups were being handled, I have no visibility into that with the cloud. How often are they moved off-site? How often do they occur? How long are they retained? Can I do a point-in-time restore on demand? Quick google on the backup/restore, it sounds like backups are a manual process unless you buy a 3rd party tool!
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
July 5, 2021 at 4:18 pm
While I don't see it as causing any serious issues, I'll state again that I find that applications that require snapshot isolation to get performance to be annoying at best. It's not that I have a whole lot against the use of snapshot isolation. I've just found that people use it as an excuse for not writing quality code. It's a lot like people that try to kill performance problems with iron. Sometimes it works but, if your multirow code won't go parallel because of the way it's written, extra iron isn't going to help. Of course, going parallel can actually cost you a whole lot, as well. There is no "panacea" of performance when it comes to such things. Performance is "in the code... or not".
Just curious - are you referring to RCSI or just enabling the option to allow snapshot isolation? Is your argument against enabling this feature just because it might be hiding 'bad' code - or do you find that using this should never be done, on any system?
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
July 5, 2021 at 4:26 pm
On premise means we can limit access a lot better and we have control of the backups and the raw data (filesystem and database). Plus on premise (Server) is cheaper than cloud and some addons we use don't have cloud options.
Once it is in the cloud, we lose a lot of control. This is true for all cloud based tools. If we wanted to do backups nightly with VM snapshots hourly, we can do that. If we only want to do weekly backups and no snapshots, that's fine too. We can do whatever we are comfortable with. PLUS when doing application upgrades, we can plan them and test them on our test/dev systems prior to doing it on live AND we can ensure that test and live are perfect clones of each other prior to doing the upgrade too. With cloud systems, we are trusting the vendor to provide the test and live environments to be identical and it may not be the case which COULD cause upgrade issues.
My preference is always on premise as I like having control of the systems I am managing. I know how things are configured or know who to ask for both the server and application side. If our auditors (for example) wanted to know how backups were being handled, I have no visibility into that with the cloud. How often are they moved off-site? How often do they occur? How long are they retained? Can I do a point-in-time restore on demand? Quick google on the backup/restore, it sounds like backups are a manual process unless you buy a 3rd party tool!
I have to ask what exactly are you doing in Jira that needs a test / prod environment or that managing your own backups is important?
July 5, 2021 at 7:09 pm
ZZartin - we are tracking a lot of things related to products we build such as which CVE's apply to them and what bugs are being worked on. We also assign cross-department and cross-division tasks for products through Jira. Our company relies on Jira and having downtime results in some pretty high level people calling me to figure out what is wrong and when it'll get fixed.
So if we are installing any new plugins, we need to run it through test first. If we do any major changes, such as version updates or plugin changes (updates or new ones), we need to test it on the test system prior to doing it on live. We have had some issues where plugins cause odd issues that should be unrelated to the plugin we installed.
On top of that, we do some customizations and automations on our systems and when setting those up, it is much safer to run them through the test system first to make sure there are no issues.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
July 5, 2021 at 7:56 pm
That makes sense, I was curious since we're using stock jira/confluence, so it's mostly just for an information store and communications not really process oriented.
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply