feature request: concurrency limit

[vikstrous2]

What happened?

We are running gqlgen with a large garphql and a mix of large and small queries. We want to achieve predictable performance for small queries and prevent them from being starved for resources from large queries.

What did you expect?

We expected to be able to set a parameter to limit the total number of concurrently executing resolvers per request.

Minimal graphql.schema and models to reproduce

n/a

versions

• gqlgen version? all versions
• go version? n/a
• dep or go modules? n/a

---

We found the following way to implement a concurrency limit in a middleware:

mux := sync.Mutex{}
srv.AroundFields(func(ctx context.Context, next graphql.Resolver) (res interface{}, err error) {
        mux.Lock()
        defer mux.Unlock()
        return next(ctx)
})

I'm showing a limit of 1, but you'd normally use a semaphore, of course.

The down side of this approach is that it doesn't limit the number of goroutines created. I was hoping for a more built-in way to limit concurrency without having a large number of blocked goroutines.

[kidoman]

We are facing a similar issue.

Due to the full parallel execution of resolvers, it can cause connection pool issues at a container level. What is the recommendation here?

[let4be]

In a custom solution you'd also need to account for context cancellation, so it won't be as trivial as mentioned above
Locking unconditionally on a mutex is just bad