You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We do observe that around 30% of the KV server calls are not followed by an execution of our bidding script (generateBid). The execution of generateBid, at its very beginning registers forDebuggingOnly.reportAdAuctionLoss so that we are sure to receive a notification server side if generateBid is triggered.
We investigated the impact of the size of the bidding script on that phenomenon.
For that we conducted two tests:
The first test is to increase the size of the production bidding script.
For that we add a dummy payload to the script. This payload can be of an arbitrary size.
We consider the size as seen server side before any compression mechanism.
The production bidding script if around 100KB
We use the no-cache response header, indicating that the script can be stored in caches, but the response must be validated with the origin server before each reuse.
We tested adding 100KB, 200KB, 400KB and 800KB
The second test is to reduce the size of the bidding script. For that we build a minimal bidding script where we remove all logic in generateBid. It only registers a call to forDebuggingOnly.reportAdAuctionLoss and returns a constant bid (-1). reportWin does nothing.
This minimal script is of size 1KB. We still have the capacity to add a dummy payload to it.
We tested with script sizes 1KB (the minimal script) and 25KB (the minimal script plus a dummy payload of 24KB)
The test ensures we have the same number of calls to the bidding script endpoint in the reference population and in the test population.
We measure the relative increase in participation as : (number of reports received in TEST - number of reports received in REF)/(number of reports received in REF)
The results show a clear relationship between the size of the bidding script and the number of generateBid executions :
size (KB)
relative increase in participation
1
+11.5%
25
+7.6%
100 (current size = reference)
0
200
-24%
300
-26%
500
-37%
900
-46%
This causes several issues
We are limited in improving our bidding logic and added value for our customers.
We suffer from a loss of opportunity while still fully supporting the infra-cost for these missed opportunities. The KV server is called while the bidding script is loading.
Are there any mitigation proposal to minimize this effect?
And more generally what would be the possible reporting solutions to measure why we lose opportunities (the size of the bidding script being one of them)?
The text was updated successfully, but these errors were encountered:
We do observe that around 30% of the KV server calls are not followed by an execution of our bidding script (
generateBid
). The execution ofgenerateBid
, at its very beginning registersforDebuggingOnly.reportAdAuctionLoss
so that we are sure to receive a notification server side ifgenerateBid
is triggered.We investigated the impact of the size of the bidding script on that phenomenon.
For that we conducted two tests:
The first test is to increase the size of the production bidding script.
For that we add a dummy payload to the script. This payload can be of an arbitrary size.
We consider the size as seen server side before any compression mechanism.
The production bidding script if around 100KB
We use the
no-cache
response header, indicating that the script can be stored in caches, but the response must be validated with the origin server before each reuse.We tested adding 100KB, 200KB, 400KB and 800KB
The second test is to reduce the size of the bidding script. For that we build a minimal bidding script where we remove all logic in
generateBid
. It only registers a call toforDebuggingOnly.reportAdAuctionLoss
and returns a constant bid (-1).reportWin
does nothing.This minimal script is of size 1KB. We still have the capacity to add a dummy payload to it.
We tested with script sizes 1KB (the minimal script) and 25KB (the minimal script plus a dummy payload of 24KB)
The test ensures we have the same number of calls to the bidding script endpoint in the reference population and in the test population.
We measure the relative increase in participation as : (number of reports received in TEST - number of reports received in REF)/(number of reports received in REF)
The results show a clear relationship between the size of the bidding script and the number of generateBid executions :
This causes several issues
Are there any mitigation proposal to minimize this effect?
And more generally what would be the possible reporting solutions to measure why we lose opportunities (the size of the bidding script being one of them)?
The text was updated successfully, but these errors were encountered: