feat: limit number for active requests #5107
Conversation
- avoid locking up the service by flooding service with requets
|
can you please add why this change? |
Many of our deployments are exposed to the open internet, with some—such as catalogues—actively promoting their services online as part of their core use case and business value. However, being publicly accessible also means these services are susceptible to high volumes of incoming requests, which can overwhelm the system. This has occurred multiple times over recent days, months, and even years. The current architecture and deployment configurations are optimized for a very small number of concurrent users. In reality, only a tiny fraction of internet-connected machines are legitimate users. To prevent overload from excessive traffic (e.g., DDoS attacks, aggressive web scraping, or automated bot requests), this PR introduces a mechanism to limit the number of concurrent upstream requests. The limit is currently hard-coded but should ideally be configurable via environment or runtime settings. The goal is to select a threshold that maximizes resource usage during normal operations without degrading performance or risking system instability due to factors like garbage collection pauses, memory swapping, or excessive context switching. |
|
What are the main changes you did
How to test
Checklist