Sensible defaults for network throttling

[paulb-elastic]

Although the more rounded solution for network throttling is defined in #210, this is to at least provide sensible defaults for all monitors.

As a Synthetic user
I want all monitors to run with a sensible network throttling configuration
So that they don’t run at line speed and result in variable performance metrics based on how busy the network is

ACs:

• Determine a reasonable default network speed (upload speed, download speed and latency)
• Apply these to all monitors that run in Synthetics (inline, suites, heartbeat.yml, Fleet Integration)
• It is possible to override these defaults for specific monitors (e.g. via the script as shown in Network throttling #210 (comment))

Heartbeat issue here: elastic/beats#27952

[paulb-elastic]

Discussed in refinement, and suggested defaults as:

• download: 5mbps
• upload: 3mbps
• latency: 20ms

[dominiqueclarke]

Will override options be exposed as heartbeat parameters at any point @andrewvc

[vigneshshanmugam]

In addition to having defaults, We need to have a add a CLI arg to disable throttling. --no-throttling should disable the sensible default throttling and would use the available network bandwidth as it is now.

[shahzad31]

Post FF Testing,

i need some help testing, how can we know throttling is being applied?

for example i am running like this

cat examples/inline/short.js | npx @elastic/synthetics --inline --throttling 5d/3u/20l --no-headless

So i was expecting in the chrome network tool, throttling will be applied

but it still showed no throttling

cc @dominiqueclarke

[paulb-elastic]

You can visit a page or URL with a specific payload size (e.g. a large bitmap image can be good) and compare how long the download takes with different speeds, and also compare to the theoretical download duration based on size and speed. Similarly with upload throttling, POSTing a payload of a particular size.

Latency may be harder, as I don’t think you’ll see the impact for example on a SYN/ACK (TCP connection time) with emulated latency in Chrome.

It’s a good point about seeing the settings in the devtools UI - not sure if we should expect these to show the settings. That would be useful to confirm the throttling settings have been made.

[dominiqueclarke]

Per @vigneshshanmugam, the CDP session set through playwright and the CDP session in the dev tools are actually two different settings, and the devtools does not directly correlate to the CPD session anyway.

@vigneshshanmugam Please clarify if I misquoted you.

@shahzad31 your best best is tested via the recommended approach from Paul.

[vigneshshanmugam]

@dominiqueclarke ++.

@shahzad31 They are two different instances of CDP session, so the chrome UI would not have any clue on what settings have been applied on the given session in any way.

Another way to test would be to check the Network information API on the throttled page https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation

[shahzad31]

So i am using CLI to test this feature

first i tried this command

cat examples/inline/short.js | npx @elastic/synthetics --inline --throttling 10d/3u/20l --no-headless

in this browser i first tried NetworkConditions api,

i can see the downlink speed being applied

i also tried fast.com speed test and it reflect the relevant throttling being applied

another test case

cat examples/inline/short.js | npx @elastic/synthetics --inline --throttling 5d/3u/20l --no-headless

This was also reflected properly.

With --no-throttling flag,

it reflected my connection speed

without any flag being passed to cli, it reflected defaults

cat examples/inline/short.js | npx @elastic/synthetics --inline --no-headless