Incremental scans slow on FishEye + Git

[David Yu]

I normally wouldn't be bugged by a scan that takes about 15 minutes but when you have developers that need to create reviews of code they pushed in, it's making the Crucible usage experience not that great.

What I'm seeing happen is when someone does a small commit/merge, FishEye does a git ls-tree that seems to recursively iterate each git object with this operation:

searching changeset ancestry of e0b9d469d62d02fe2933fd84d3b0385bc
ee555ba

I was somewhat prepared to expect a slow initial repo scan ( https://jira.atlassian.com/browse/FE-3461 ) but did not expect incremental polls to take this long as well.

Is there anything I can do to speed up the incremental scans? I've already tried adding EXCLUDE paths to directories where several thousand library files live but I'm still seeing the "search changeset ancestry" operation occur on these paths.

The repo has about 50 branches, and 7,000 files in master branch.

[Gurleen Anand [Atlassian]]

Hi David,

Have you tried the suggestion from this KB article:

https://confluence.atlassian.com/pages/viewpage.action?pageId=299569512

Thanks,

Gurleen

[Gonchik Tsymzhitov]

Thanks! 

It helps.

Cheers,

Gonchik Tsymzhitov

[David Tweet]

I am seeing the same issue on our largest git repository, but with delays of multiple hours. Fisheye appears to iterate through the entire repo each time the index needs to be updated, even when the intervening commits are very minor. Pursuing this issue with Atlassian support right now.