Woodpecker-CI performance with large GitLab instances

[jgoelen]

We've recently set up Woodpecker-CI and connected it to our on-premises GitLab server using the GitLab forge. However, we're experiencing significant performance issues, particularly during login and when adding repositories. Our GitLab instance contains numerous teams and members, which seems to be exacerbating the problem.
Our observations:

Login times are very slow, taking several minutes to complete.
Adding a repository also takes an unusually long time.
GitLab access logs show that Woodpecker is making a large number of API requests to fetch data.

Here's a sample of our GitLab access logs, showing the pattern of requests:

1.2.3.4 - - [15/Oct/2024:14:26:17 +0200] "GET /api/v4/projects?archived=false&min_access_level=30&page=1&per_page=100 HTTP/1.1" 200 29134 "" "go-gitlab" 14.45
1.2.3.4 - - [15/Oct/2024:14:26:17 +0200] "GET /api/v4/projects/2842/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:17 +0200] "GET /api/v4/projects/2841/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:18 +0200] "GET /api/v4/projects/2840/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:18 +0200] "GET /api/v4/projects/2839/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:18 +0200] "GET /api/v4/projects/2838/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:19 +0200] "GET /api/v4/projects/2836/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:19 +0200] "GET /api/v4/projects/2835/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:19 +0200] "GET /api/v4/projects/2834/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:19 +0200] "GET /api/v4/projects/2831/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:20 +0200] "GET /api/v4/projects/2830/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:20 +0200] "GET /api/v4/projects/2829/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:20 +0200] "GET /api/v4/projects/2827/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:21 +0200] "GET /api/v4/projects/2826/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:26:21 +0200] "GET /api/v4/projects/2825/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82

....

1.2.3.4 - - [15/Oct/2024:14:30:32 +0200] "GET /api/v4/projects/1523/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:30:33 +0200] "GET /api/v4/projects/1522/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:30:33 +0200] "GET /api/v4/projects/1360/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:30:33 +0200] "GET /api/v4/projects/1320/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:30:33 +0200] "GET /api/v4/projects/1010/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:30:34 +0200] "GET /api/v4/projects/1009/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82
1.2.3.4 - - [15/Oct/2024:14:30:34 +0200] "GET /api/v4/projects/533/members/all/161 HTTP/1.1" 200 331 "" "go-gitlab" 1.82

As you can see, Woodpecker is making individual API calls for each project's members, which is causing a significant delay.
Questions:

Is this behavior expected for large GitLab instances, or could there be a configuration issue on our end?
Are there any known optimizations or settings we can adjust to reduce the number of API calls and improve performance?
Is there a way to batch these requests or implement caching to reduce the load on our GitLab server and speed up the process?
Are there any plans to optimize this process in future Woodpecker-CI releases?

Any insights or suggestions would be greatly appreciated. We're eager to use Woodpecker-CI but need to address these performance concerns first.

[qwerty287]

Duplicate of #2502 ?

[jgoelen]

Yes ... seems to be the same problem.

[qwerty287]

OK. I'll close this one then. if there's something in this discussion that's not in the issue yet please comment on the issue again.