Question on Single-Instance Performance (Docker Deployment with Embedded PostgreSQL)

koksime.yap_5909

Hi ProGet team,

I came across the blog post mentioning that high traffic from around 50 or more users on a single-server ProGet instance can lead to issues such as HTTP request timeouts, unhandled exceptions, and temporary service unavailability.

I’d like to understand more about the performance capacity of a single ProGet instance, particularly when running the official Docker image with the embedded PostgreSQL server.

The documentation lists the recommended container sizes (up to 4 vCPU and 8 GB RAM for “Large”), but I’m wondering:

What kind of workload or number of concurrent requests the “Large” configuration is expected to handle reliably
Whether scaling resources beyond that point would improve performance
Or if it’s generally more effective to move to an external PostgreSQL setup or a load-balanced configuration instead

Any guidance, documentation, or internal benchmarks on this would be greatly appreciated.

Thanks!

stevedennis

Hi @koksime-yap_5909 ,

I'm afraid we can't provide much clearer guidance than that, as there are so many factors involved that make predicting performance basically impossible. For example, the feed types you're using, your CI server configuration, how often developers are rebuilding, etc.

The article you found is actually what we send users who experience symptoms of server overload, to help understand where it comes from and how to prevent it. As the article mentions, the biggest bottleneck is network traffic during peak traffic - there's only so much that a single network card can handle, and scaling CPU/RAM doesn't really help.

This is where load-balancing comes in. The main downside is complexity/cost, which is why a most customers start with a single instance. It can take quite a while for a tool like ProGet to be fully onboarded across teams, so performance problems likely won't happen at first.

Hope that helps, let us know if you have any other questions!

Thanks,

Steve