Subversion plugin. Getting told by Network team that we have high bandwidth utilization caused by this plugin and

Subversion plugin. Getting told by Network team that we have high bandwidth utilization caused by this plugin. Any ideas?

3 answers

I would ask them for figures, how much is too much?

It runs on a service and checks subversion every x mins. You could dial it back and get the service to run once every half an hour?

How many repostories have you configured?

I had 8 configured with the service to run every 5 min. The results of that was that every 5 min it was taking about 3.5Mbs which was saturating our entire WAN. What's strange is that the repos that I had configured weren't even very active, cause we only have about 8 java programmers. I changed it to run only once every hour. My question though would be, under the covers of the plugin, is it doing an svn log with the deltas only? Or is it getting the entire svn repo every 5 min? I would assume the former....

If a large repository has just been registered, then the cause might be that the plug-in is downloading the whole history in order to locate JIRA issue keys embedded in comments. After the full repository has been indexed you should notice a considerable reduction of the bandwith consumption.

Furthermore, if there are a lot of users using the plug-in extensively, then the reason could be that the plug-in access to Subversion in order to download the item paths for each commit displayed on the JIRA issue or project page. This happens every time that the page is rendered. As Subversion requires a lot of bandwith in order to transfer such information, you can use this fork of the plug-in:

https://marketplace.atlassian.com/plugins/pbeltranl.subversion.jira.pbeltranl-jira-subversion-plugin

The fork resolves this problem by caching the full repository history (including the item paths), hence there is not any invocation to Subversion in order to display any Subversion data on JIRA. The bandwith is consumed only to transfer the data between the JIRA Server and the JIRA page. The Subversion data is cached in a relational database on the server and you should notice a better performance and less bandwith consumption.

Hope this helps.

Ooops, just readed your second post...

Well, it might be due to how the Atlassian plugin deals with the latest indexed revision: it donwnloads the history from the latest commit (HEAD) on Subversion and the latest indexed commit (by the plug-in). As the plug-in only indexes a commit if a JIRA issue key is embedded in the comment, then it scans for ever those commits until a new JIRA issue key is found.

For example:

r1000 includes a JIRA issue key in the comment -> it is indexed by the plug-in.

The users commits 500 changes -> The repository HEAD is r1500

The plug-in index services starts -> gets (downloads) the latest 500 commits -> no any JIRA issue key found in any commit -> The index service stops.

5 minutes later...

starts the loop again.

This issue is also fixed by the fork.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,188 views 13 19
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot