General JIRA Usage with large attachments

[Deleted user]

Hi everyone

This is not a specific question, but I'm hoping to get some input as to how my small department is using JIRA.

A year ago, we started using JIRA and we were very happy with the many options and how fast we could adapt it to our needs. We have a server hosted at a company near us and everything has been working great.

This summer, it was decided to try and use JIRA, not only as our workflow, but also as a database for the many files we use in our production. Files, which often are around 1gB.

Being a bit worried, by this sudden influx of large files (1gB-file to around 1000 issues and rising) I asked our hosting company, if they saw any problems with this approach. They did not.

Fast forward to now, our JIRA instance is running very poorly. Originally, we had simply run out of disk space, but after increasing that this week, we are still facing performance issues. For more info, we have around 30.000 issues in total, 100 custom fields and around 1000-2000 issues with large attachments and rising.

I asked our hosting company, to look into increasing the performance on the server our JIRA instance is running from, but they charge a significant price for this.

My question is then:

Do you consider our use of JIRA, as production database, as a good idea?

It is reasonable to continue down this road and upgrading our server?

Will the server upgrade even fix the problems of bad performance, or is there underlying architecture in JIRA, that makes it bad at handling this way of using it?

If this question is not meant for this board, I am sorry.

/Nikolaj

[Renjith Pillai]

How about a scripted field that displays the difference between these custom fields that you are storing during your transistion?

https://plugins.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner

[Filipe Do Monte]

Thanks for your answer.
If I understand well, you suggest to calculate a difference between "the time when I enter the status Pending" and "the time when I go back to In Progress". Actually it could work if I do this transition only one time.

But during the lifecycle of the object, we could performed several time this transition, the date will be then systematically overwritten and I will not have the complete time spent on the Pending status (only the last one).
Currently on the transition tab, the time is always added and only one appears even for several transitions "Pending --> In progress". (I hope I'm clear :))
That's why for me, extract this time would have been the best.

[Renjith Pillai]

May be before overwriting, take the existing value from the customfield sum it up and store again?

[Angell Tsang]

You could design your workflows to only allow that initial status to exist once, and any loop back would be a completel different status.