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

Jason Stein June 6, 2013

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

3 answers

0 votes
Kinto Soft
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 6, 2013

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.

Kinto Soft
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 6, 2013

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.

0 votes
Jason Stein June 6, 2013

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....

0 votes
MatthewC
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 6, 2013

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?

Suggest an answer

Log in or Sign up to answer