start up delays & cold-starts

[aliraza0337]

This is great :)
Does this simulator take into consideration startup delays for VMs and also cold-starts for the serverless functions? If not what would be the best to incorporate that?

[timonback]

Thanks!
Currently it does not take it into account as the project was designed to find an optimal VM/FaaS instance configuration based on a request pattern that is already known. Therefore, the assumption was made that cold-starts and start-up delays can be avoided by starting the VMs beforehand just so that they become ready in time. What do you try to achieve?

Accounting for cold-starts of serverless functions I would probably change/manipulate the input data so that the first n requests take longer to execute. This can be done based on the input data or programmatically. This could be a place to start investigating:

thesis-msc-simulator/simulator/resource/instance_creator_faas.py

Line 28 in 684e01e

adjusted_duration = duration * degradation_factor

As for the VMs, I would probably also edit the input parameters by changing the actual duration of a VM

thesis-msc-simulator/simulator/resource/instance_creator_vm.py

Line 47 in 927d347

cost, memory, btu, dynamic = self.pricing.get_price(memory_needed)

However, there is the issue that would likely apply for all VMs regardless whether they were newly started or kept running.
A better solution would be to change simulator logic to first simulate a load only with FaaS and then slowly start switching load to VMs (currently it is the other way round, see

thesis-msc-simulator/simulator/runner.py

Line 52 in 927d347

# run vm simulation

) However, then the question/optimization problem becomes deciding which individual requests to bundle up together and hand over one or multiple VMs.