Subversion plugin. Getting told by Network team that we have high bandwidth utilization caused by this plugin. Any ideas?
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:
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.
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.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG