Potential performance impact of embedded Crowd directory ordering

Still need help?

The Atlassian Community is here for you.

Ask the community

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.

Last modified on Jul 31, 2018

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.