Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apply DevTool Network/CPU throttle to FLEDGE #387

Open
zhengweiwithoutthei opened this issue Oct 26, 2022 · 7 comments
Open

Apply DevTool Network/CPU throttle to FLEDGE #387

zhengweiwithoutthei opened this issue Oct 26, 2022 · 7 comments
Labels
Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility

Comments

@zhengweiwithoutthei
Copy link

We use DevTool to profile the performance of running FLEDGE auction. We were hoping to leverage the Network/CPU throttle to simulate user's experiment with lower end devices or slow internet connection. However, we noticed that those features in DevTool seems have no effect on FLEDGE network request and execution in worklets.
I think it will be very useful if Chrome can make those features apply to FLEDGE too.

@JensenPaul
Copy link
Collaborator

@morlovich knows a lot about the FLEDGE integration with DevTools

@morlovich
Copy link
Collaborator

So I have an idea on how to do the network part (notes below); for the CPU part, could you tell me (or screenshot if you can do it w/o any sensitive stuff) where the option is so I can chase down which devtools protocol calls it tries to make?

Notes on network part:
We will need a NetworkHandler (which we want for the network panel anyway, not sure of all of its requirements, though), and then make sure that the token passed to its constructor is also passed to this field in the request:
https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/resource_request.h;drc=27e39fa1dd71076618c358639ed8a327bc3873c4;l=165

We could have AuctionURLLoaderFactoryProxy fill in the token, in which case:
https://source.chromium.org/chromium/chromium/src/+/main:content/browser/interest_group/auction_worklet_manager.cc;drc=27e39fa1dd71076618c358639ed8a327bc3873c4;l=156 is code that both deals with the loader proxy and DebuggableAuctionWorklet, so it can linked it through down to the handler, too.

Alternatively the worklet process can just fill it in (passing those to lower-trust processes is OK), and we could pass it in to the worklet request stuff right at the same spot.

@zhengweiwithoutthei
Copy link
Author

Thanks, the options are on the performance tab, click the gear icon to expand the ui.

image

@morlovich
Copy link
Collaborator

Thanks. That looks to be https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setCPUThrottlingRate
Sadly existing implementation looks tied to blink internals, so probably not usable for us.
(I suppose we can have a wrapper around a TaskRunner that wraps each task with a callback that measures its runtime and then sleeps for n times it, though it's rather crude and may end up messing with debugging).

@JensenPaul JensenPaul added the Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility label Jun 22, 2023
@HabibiYou
Copy link
Contributor

Network throttling will now affect Protected Audience auctions. You can find the change here. This does not include CPU throttling as that is not as easily accessible to us.

@dmdabbs
Copy link
Contributor

dmdabbs commented Sep 27, 2023

Thank you @HabibiYou. Would you kindly please post the related Monorail link?

@HabibiYou
Copy link
Contributor

No problem, and sorry @dmdabbs but we actually don't have one for this issue. The solution came as we were working on issue #778.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility
Projects
None yet
Development

No branches or pull requests

5 participants