V1 Composer package registry endpoint request takes >30 seconds

Summary

Composer will read the package registry endpoint to retrieve new info about package updates. When a GitLab package repository has been configured, the URL Composer reads is https://<gitlab host>/api/v4/group/<groupid>/-/packages/composer/packages.json per repository.

Below is the contents of what that endpoint returns (with some variables masked). It's not much, yet this endpoint takes 30 to 60 seconds to load. The group contains 27k+ packages. It's starting to become so slow that Composer fails to load it and falls back to cache if available. The only thing that looks calculated in this response is the hash, for which 30 - 60 seconds seems an awful lot. This makes the package repository almost unusable for us. Not sure if other package repositories besides Composer are affected.

This endpoint returns:

{
    packages: [ ],
    provider-includes: {
        p/%hash%.json: {
            sha256: "<hash>"
        }
    },
    providers-url: "/api/v4/group/<groupId>/-/packages/composer/%package%.json"
}

Steps to reproduce

Call the https://<gitlab host>/api/v4/group/<groupid>/-/packages/composer/packages.json endpoint for a group that contains a lot of composer packages.

What is the current bug behavior?

Loading times of 30+ seconds.

What is the expected correct behavior?

Loading times of <10 seconds

Relevant logs and/or screenshots

GitLab environment info

Version: GitLab Enterprise Edition 13.6.1-ee

Possible fixes

I thought #219171 (closed) to be related at first, but looking into more I think it's not. Though the problem/fix might still be similar?