Add a way to point a browser in a container at a given url

[mrchrisadams]

We want to simulate a user loading a page, and seeing how doing this affects the energy used by the system.

We currently think we'll do this using some system that relis on RAPL measurements

Something like this:

https://01.org/rapl-power-meter

But likely a python take on it, that already reflects some thought gone into it, like perhaps this one:

https://github.com/responsibleproblemsolving/energy-usage

Or possibly this one:

https://github.com/powerapi-ng/rapl-formula

It might be worth giving this a spin too:
https://powerapi-ng.github.io/howto_monitor_docker/intro.html

The dream

The eventual goal would be to run these headless, and integrate it into something like sitespeed.io

Blink based browsers have this:
https://docs.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/evaluate-performance/
https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/index

Firefox has this, built in by default which tracks performance here, with a focus on frame rates, and memory allocation in javascript.

https://developer.mozilla.org/en-US/docs/Tools/Performance

There is also a much more extensive profiler - this focuses mainly on how Firefox itself allocates memory.
https://profiler.firefox.com/

[mrchrisadams]

Okay, after further reading, this seems to be the difference between the two.

Both rely on RAPL measurements.

Energy usage

takes measurements every 0.1 seconds of energy used in joules¹ over the length of the work, then eventually adds these together, along with the rest of the report for a page.

This gives us a single number, but doesn't highlight hotspots or give any indication where energy usage spikes, or provide the stats that Safari does.

Power API

Power API is quite a bit more complex, and measure more than just power usage. There are two bits you need at a minimum. A sensor that reads RAPL related stats, and stores them somewhere. The common example is the hwpc-sensor, a C binary.

These stats are then read by the formula, which converts these numbers into something more meaningful, like the power usage we might care about.

This is designed to make it possible to track energy usage across multiple containers. This relies on a more complex smartwatts-formula that takes care of allocating energy use to each one.

Instructions for compiling the C binary are on the PowerAPI website
https://powerapi-ng.github.io/hwpc.html#specify-power-consumption-monitoring

Background for Power API

The following papers outline the architecture, and provide useful context, as the documentation isn't that clear.
https://ercim-news.ercim.eu/en92/special/powerapi-a-software-library-to-monitor-the-energy-consumed-at-the-process-level

https://hal.inria.fr/hal-01130030

This approach appears to be aimed at cloud infrastructure to make energy use visible with swarms of docker containers, to make better use of the infrastructure.
https://hal.inria.fr/hal-01403486

¹ for quick functions, it checks every 0.01 seconds instead.

[mrchrisadams]

Okay, further info. you can compile the binary, without any of the MONGODB guff, and just log to csv.

The -c defines what kinds of events to listen for. The -e flag in the case below tells hwpc-sensor which events to listen for.

You need to define the kind of event with -c before listing the events themselves with e.

• RAPL_ENERGY_PKG : whole CPU socket power consumption
• RAPL_ENERGY_DRAM :RAM power consumption
• RAPL_ENERGY_GPU : CPU integrated graphics processing unit

The -r and -U defines the output for the logging, and the URI to send it to.

So the final call might be:

hwpc-sensor \
  --name example-sensor \
  -c rapl
  -e RAPL_ENERGY_PKG \
  -e RAPL_ENERGY_DRAM \
  -e RAPL_ENERGY_GPU

  -r csv \
  -U /tmp/sensor_output