@wooferclaw suggested adding the functionality of a load test for the live application, which is mainly about testing the infrastructure and deployment rather than the computation capability.
We actually have smprofiler/db/scripts/load_testing.py already, but that tests specific datasets and metrics rather than infrastructure scaling etc.
I propose a new metric type, for testing only, and a new subclass of GenericJobComputer which just does dummy CPU and memory consumption for a specific mildly randomized amount of time, the duration and CPU/memory amount being based on some parameters for the metric type.
Then we will make sure that the special handlers for edge cases for the real metrics (retries, timeouts, and null-insertion, etc.) are not invoked when doing this type of testing.
@wooferclaw suggested adding the functionality of a load test for the live application, which is mainly about testing the infrastructure and deployment rather than the computation capability.
We actually have smprofiler/db/scripts/load_testing.py already, but that tests specific datasets and metrics rather than infrastructure scaling etc.
I propose a new metric type, for testing only, and a new subclass of
GenericJobComputerwhich just does dummy CPU and memory consumption for a specific mildly randomized amount of time, the duration and CPU/memory amount being based on some parameters for the metric type.Then we will make sure that the special handlers for edge cases for the real metrics (retries, timeouts, and null-insertion, etc.) are not invoked when doing this type of testing.