/workspace/{workspace-uuid}/members is slow (seconds of response time)

We where having trouble with our Bitbucket Cloud app, where the responses are slow, often getting into the 10’s of seconds or timing out. So, we started to trace the request times.

Turns out, that the /workspace/{workspace-uuid}/members is unexpected slow, taking often seconds to respond. That abysmally slow. I expect a REST endpoint with 100 entries to return in 10’s of milliseconds, or faster. The members endpoint is about 2 order of magnitude slower that I would expect it to be.

I assume that the response headers x-render-time, x-usage-user-time and x-usage-system-time are some performance metrics of processing time, because it matches the slow response time: Example values we got:

'x-usage-user-time': '1.799913',
'x-usage-system-time': '0.048344'
'x-render-time': '3.060859203338623'

So, I have a few questions:

  • Is there anything wrong with the /members endpoint that it can be this slow? Are we missing something?
  • What is the best way to check if a number of ‘Display Names’ exists in a workspace or repo? Basically what we need: We have a bunch of Display Names or Nicknames. And we need to check if these names are referring to existing users in a workspace (or repository). So, our we used the /members endpoint, because it seems the only endpoint allowing to do batch processing, where we can check a lot of Display Names at once. Other ways to do that are welcome.

PS: Worst case, we can introduce a member cache. However, that still gives a bad ‘cold start’ experience and all the issues of cache invalidation / stale caches.

2 Likes

@DanFraser, @JeroenDeRaedt
May one of you can help us here?
Thanks in advance.

1 Like

@bentley @DanFraser @JeroenDeRaedt @ibuchanan
Can you please help us here? Thanks

@michael.rueegg et al,

Thanks for commitment to getting an answer through these public community channels so that all can learn. Unfortunately, I see an issue that requires more “back and forth”, possibly with exchange of details like client id, Connect app keys, or even specific workspace ids so that engineering can better narrow the scope and understand the problem, which is better suited to a private exchange. As such, please open a ticket at:

(Edit: wrong support link provided previously)

Thanks. We contacted Atlassians support.

Hello everyone.

This issue seems to be fixed now by Bitbucket, see:
https://jira.atlassian.com/browse/BCLOUD-22291