Hi,

We would like to share our initial observations with regards to the performance of running FLEDGE auctions. This topic was previously addressed (including an issue #215) but mainly in the context of running JS in a bidding worklet environment. This time we would like to discuss potential latency bottlenecks in an end-to-end runAdAuction call.

We manage to run FLEDGE auctions in a production environment (which means real publishers, real advertisers and our bidding infrastructure with our bidding logic).

In this scenario we run a Chromium browser with FLEDGE enabled, then visit an advertiser’s page (which adds us to 3 interest groups), and finally visit the publisher’s page which runs an auction for these IGs. To measure performance we take advantage of the trace event profiling tool (chrome://tracing).

Benchmark 1 (Intel Core i7-6820HQ 2.7 GHz, Linux, fast internet connection):

Benchmark 2 (Intel Core i7-4600U 2.1GHz, Windows, slow internet connection):

Our observations:

• an auction consists of 3 sequential phases:
  • loading interest groups - getting data from sqlite database
  • bidding and scoring - running bidder and seller worklets with generateBid and scoreAd calls
  • reporting - running bidder and seller worklets with reportWin and reportResult calls
• calling JS is a small part of the entire invocation
• most of the time is spent on loading interest groups, preparing worklets and requesting signals
  • by “preparing worklets” we mean time spent in bidder_worklet_generate_bid but before both a) requesting trusted signals and b) downloading JS
• in our benchmark 1 an auction runs in ~310ms, which includes:
  • loading interest groups ~10ms
  • preparing worklets ~25ms (during the bidding and scoring phase) and ~25ms (during the reporting phase)
  • requesting trusted bidding signals ~210ms
• in our benchmark 2 an auction runs in ~2.5s which includes:
  • loading interest groups ~350ms
  • preparing worklets ~550ms (during the bidding and scoring phase) and ~250ms (during the reporting phase)
  • requesting trusted bidding signals ~1.2s

Bearing in mind that runAdAuction would be run for all participating buyers, and fetching ctx signals and ad rendering will take additional time, we are afraid that this level of latency would not be acceptable for an end user.

The latency of TBS requests could be reduced by replacing BYOS by the key-value TBS and/or by improvements proposed in #333 (TBS prefetching, caching etc.) but it is not clear what to do with the other latencies.

Are you aware of these issues? Do you have plans to address them in the future?

Best regards,
Bartosz