-
Bug
-
Resolution: Fixed
-
Highest
-
7.21.0
-
None
-
14
-
Severity 2 - Major
-
133
-
Note that this Jira issue specifically deals with (as is described below) the performance of testing pull request mergeability. This is a high impact performance concern because mergeability checks are run very frequently; for example when a user visits a pull request, to decide if the merge button should be active or not.
The second piece of the puzzle is BSERV-14066 which mitigates impact of the same change in Git, but as it applies to actually merging pull requests (i.e. when the merge button is clicked).
Issue Summary
In Git 2.38.0 a change was made to ensure Git can restore pre-merge state after a git-merge. This involves doing more work resulting in increased disk IO and CPU usage. In the context of running Git as a client this is an insignificant impact; however in Bitbucket Server this codepath is executed frequently to test the mergeability of pull request and the impact on performance of the system can be substantial. In addition some operations such as the time for the merge button on a pull request to become active may increase from a second or so to 10+ seconds for some repositories (in the case where mergability information was not already calculated and cached).
Note: This is an issue for Git installed on the server, Git 2.38.0+ is still fine for Git clients.
Steps to Reproduce
- Create a pull request in a large repository
- Navigate to the pull request and observe the time to complete "git: try merge" in the profiling logs
Expected Results
The time to run a tryMerge() should be equivalent on Git 2.38.0+ compared to versions older than 2.38.0.
Actual Results
Profiling logs indicate the time to run a tryMerge() is slower on Git 2.38.0+ compared to older versions of Git.
Workaround
Install on the server a Git version prior to 2.38. Be sure to install a version that is compatible with the version of Bitbucket Server you are running. The Bitbucket Server/DC Supported Platforms page provides compatibility information (be sure to select the correct version of Bitbucket from the version selector).
- is resolved by
-
![[JIRA Server (Bulldog)] Epic - Created by Jira Software - do not edit or delete. Issue type for a big user story that needs to be broken down.](https://bulldog.internal.atlassian.com/images/icons/issuetypes/epic.svg "[JIRA Server (Bulldog)] Epic - Created by Jira Software - do not edit or delete. Issue type for a big user story that needs to be broken down.")
BBSDEV-27963
You do not have permission to view this issue
- mentioned in
-
Page Failed to load
-
Page Failed to load
-
Page Failed to load
-
Page Failed to load
-
Page Loading...
-
-
-
-
-
-
-
-
Performance regression running Bitbucket with Git 2.38.0+
-
-
Resolution: Fixed
-
Highest
-
7.21.0
-
None
-
14
-
Severity 2 - Major
-
133
-
Note that this Jira issue specifically deals with (as is described below) the performance of testing pull request mergeability. This is a high impact performance concern because mergeability checks are run very frequently; for example when a user visits a pull request, to decide if the merge button should be active or not.
The second piece of the puzzle is BSERV-14066 which mitigates impact of the same change in Git, but as it applies to actually merging pull requests (i.e. when the merge button is clicked).
Issue Summary
In Git 2.38.0 a change was made to ensure Git can restore pre-merge state after a git-merge. This involves doing more work resulting in increased disk IO and CPU usage. In the context of running Git as a client this is an insignificant impact; however in Bitbucket Server this codepath is executed frequently to test the mergeability of pull request and the impact on performance of the system can be substantial. In addition some operations such as the time for the merge button on a pull request to become active may increase from a second or so to 10+ seconds for some repositories (in the case where mergability information was not already calculated and cached).
Note: This is an issue for Git installed on the server, Git 2.38.0+ is still fine for Git clients.
Steps to Reproduce
- Create a pull request in a large repository
- Navigate to the pull request and observe the time to complete "git: try merge" in the profiling logs
Expected Results
The time to run a tryMerge() should be equivalent on Git 2.38.0+ compared to versions older than 2.38.0.
Actual Results
Profiling logs indicate the time to run a tryMerge() is slower on Git 2.38.0+ compared to older versions of Git.
Workaround
Install on the server a Git version prior to 2.38. Be sure to install a version that is compatible with the version of Bitbucket Server you are running. The Bitbucket Server/DC Supported Platforms page provides compatibility information (be sure to select the correct version of Bitbucket from the version selector).
-
Ben Humphreys
-
- Affected customers:
-
12 This affects my team
- Watchers:
-
24 Start watching this issue
- Created:
- Updated:
- Resolved: