We have noticed the performance impact described below with our internal Bitbucket Server instance and report this for the benefit of the wider Bitbucket Server community.

We noticed that the directory setup on a Bitbucket Server instance could be improved by reordering the directories.

We observed high rates of requests from the Bitbucket Server instance to a Crowd instance for authentication of Bamboo build users in the internal Bitbucket Server directory. 

As an interim workaround we reordered the directories to avoid trying to authenticate the build user accounts against Crowd.

The problem

Say you've got a number of directories defined in Bitbucket Server in the following order:

• Remote Crowd directory
• Internal directory

If a user from the internal directory tries to authenticate, Crowd will currently:

• attempt to authenticate against the first directory, resulting in a remote call to Crowd. Crowd won't find the user and returns a 400.
• attempt to authenticate against the second directory, where the user is found and authentication succeeds.

This means that every authentication pays the cost of a call to the remote Crowd server. 

This scenario is not unrealistic. In many cases the Crowd/LDAP directory should be the primary directory and a second internal directory may exist for non-standard users, typically for automated systems such as Bamboo and Fisheye.