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.