chore(flamegraph): Lower number of concurrent reads

[Zylphrex]

The new flamegraph endpoint is very likely the suspect of the OOMs we've been seeing. Upon examining the old flamegraph endpoint, we used to spawn ~25 go routines per request but at a lower throughput. So having 100 concurrent workers may be the cause of the OOMs as we try to read too many profiles at once.

[viglia]

The new flamegraph endpoint is very likely the suspect of the OOMs we've been seeing. Upon examining the old flamegraph endpoint, we used to spawn ~25 go routines per request but at a lower throughput. So having 100 concurrent workers may be the cause of the OOMs as we try to read too many profiles at once.

a few clarifications:

• previously we used to spawn a set for individuals goroutines for each requests, meaning that each request would be guaranteed those routines to download the profiles, with the new pool approach that's not the case. We have a shared pool and different requests compete to access the routines and download chunks
• we were not limited to ~25 goroutines per request. We had a dynamic allocation based on number of profiles. Roughly 5 goroutines every 100 profiles. Given that we were limiting the max number of profiles to use in aggregation to 600 we happened to be around that number but it could have been less or more depending on the number of profiles
• such limit (600) was later resized to 300 in this PR. Quite frankly I don't remember why it was lowered as there is no comment/description on the PR.

With that said, let's try to lower the pool to 25 and see how it behaves. Hard to tell in advance, but keep in mind that this is shared among different requests.

[Zylphrex]

The other difference is that the old flamegraph endpoint was much less frequently used compared to this one so we need to restrict it better.