Support for limiting the number of interest groups processed by buyer

[maciejkowalczyk]

Limiting the number of processed interest groups is important for managing operational costs.
Additionally, it has a direct impact on latency — for instance, unless the number of vCPUs in a Bidding Service node significantly exceeds the number of generateBid() executions required to handle a single GenerateBidsRequest.

For the browser-side auctions there is an perBuyerGroupLimits auction parameter that limits the number of interest group processed in the priority order.
On server side, however, it might be more suitable to introduce a buyer-controlled configuration parameter to achieve similar functionality.

[chatterjee-priyanka]

Thanks for the issue.

We can introduce a buyer controlled config, but few questions first:
(1) Would you like to just configure an upperbound? Curious, how would that be determined, is that looking at the tail in IG distribution?
(2) Do you expect a large variance in number of IGs per user / auction basis?
(3) Would this also be a function of number of Roma workers and consider your throughput / latency targets of each Bidding instance?
(4) Assuming a buyer sets a limit, based on what algorithm would Bidding drop the IGs before dispatching work for Roma executions?

Separately:
(4) Do you use this feature this? B&A supports that for parity with on-device auctions.