hobbit-project / platform

HOBBIT benchmarking platform
GNU General Public License v2.0
23 stars 9 forks source link

Multiple containers for a system #258

Open smirnp opened 6 years ago

smirnp commented 6 years ago

Hi! Is there any opportunity to run several instances of systemAdapter containers, like it is done for data generators and task generators? E.g. to run them from a systemAdapterContainer with id=0.

I'm just writing master-slave systemAdapter implementation, but and it requires two different images for system adapter (slaves who will not send a system ready signal) and it looks too complicated, since the platform already has such a mechanism for data and task generators.

May it is just enough to add a calculation of System_Ready_Signals according to amount of started systemContainerIds and it will properly will start a benchmark after all replicas of SystemAdapter will be ready.

MichaelRoeder commented 6 years ago

It is not supported directly because the platform wants to have one single contact point for each - the benchmark and the system. For the benchmark, the benchmark controller is taking over this role while for the system, the system adapter is the contact.

Note that the platform does not have a support for multiple data or task generators. The benchmark controller takes care of that. We have a similar implementation for a system adapter that uses a master-slave architecture: https://github.com/hobbit-project/gerbil-benchmark/blob/master/gerbil-nif-system-adapter/src/main/java/org/hobbit/benchmark/gerbil/NifSystemAdapter.java However, please note that there is a small detail that you may not like in this simple implementation: the master adapter is not waiting for the SYSTEM_READY signals of its slaves. It will first create the slaves before creating the system that he will forward incoming tasks to. After that, it will directly send the SYSTEM_READY signal to the platform. The platform will start the benchmark and at that point in time not all slave adapters might be fully started. In our use case this didn't created a real problem until now because the slave adapters are pretty fast in initializing. However, the implementation is sub-optimal at that point at the moment :disappointed: