Wiki and JIRA really slow?

Has anyone else noticed that the wiki and JIRA seem to have become really slow of late? Do we know if there is anything we can do about this? If it’s a matter of money, is there a chance we could get some funds allocated to this? I didn’t want to just email the helpdesk, because I realize it might be something outside of their control.

Take care, Mark

2 Likes

I’ve definitely noticed, though I feel like this has been a long-standing problem. I feel like I have heard that this is due to our hosting arrangement. I would LOVE to see this improved. If there is anything I can do to help, please let me know!

I am not aware of any major impact in the recent past; rather, we have seen just a gradual decline of performance as usage/activity/user count increases. We have over 1,500 wiki personal spaces created (we have recently disabled the creation of any new spaces), and currently 54,502 users, most of which are inactive or spammer accounts who are able to overcome our industry-standard signup captchas, email address validation, and IP block lists. These numbers seem to be too large for Atlassian products (designed at the high side for huge corporations that still usually have than half the number of users) to handle.

We have been looking at effective ways to restrict access to JIRA & Wiki to known contributors. It is worth noting that other large open source communities, such as Apache, operate their JIRA & Confluence systems by granting accounts only upon request.

Yes, there are several options. We have already exhausted our ability to “scale up” to improve performance of our Atlassian software, and there are no more resources available to us in our donated VM infrastructure from Indiana University’s XSEDE program. So if we stay with the same tools, it is a matter of “scaling out” capacity to additional servers, which will require significant engineering effort, time, and money. Alternatively, we could adopt one of many other more modern tools for documentation and issue tracking that can handle larger capacity and are much less resource-intensive. This approach also would require a fair bit of engineering effort as well as will be somewhat disruptive to the workflow of the community.

Unfortunately, I’m not aware of any funding currently available to support any future growth of OpenMRS infrastructure, or to support more dedicated volunteers to be more heavily engaged to improve its performance. In the 2016 operational plan, we have requested funding for a full-time infrastructure engineer, as well as modest additions to our hardware capacity. We are hoping that the OpenMRS community can secure a steady flow of funding to allow our infrastructure to grow with demand, rather than trying to chase it, or even begin to lag behind.

Thanks Michael!

Lots of things to consider here. I think we’ve like to try avoid changing tools if at all possible. We certainly don’t have 50k+ active users. Granting accounts only upon request seems reasonable to me.

Whatever we do, it seems like a large part of the work would be to just analyze what would be most effective and figuring out how best to implement it. So I strongly support prioritizing getting funding for a full-time infrastructure engineer… let me know if there’s some formal way I should voice my support! :slight_smile:

Take care, Mark

1 Like

This conversation is a great start :slight_smile:

Also, I’d encourage those interested to think through, comment, and keep an eye on this issue, which we hope to resolve during GSoC this year (along with other improvements that will help with the spam issues):

ID-127