Open felipevicens opened 7 years ago
Job created.
Next up: Job description.
@felipevicens @mpeuster @hadik3r :
Hi Guys,
What do you understand under a stresstest for the MANO framework? I've made a first attempt at describing such a test (see original post of this issue), but I'm wondering how far we should go in this. The problem with this description is that it relies heavily on the speed of the IA and the used VIM, which might not be the purpose of this test. On the other hand, by testing the MANO framework speed isolated from the lower level, this info might not very useful (In general, the MANO framework time consumption is a fraction of the total deploy time, most time is lost in the VIM part).
Do we stresstest plugins individually (Checking how long it takes in different sets to i) register a plugin, ii) onboard SSMs, iii) ... )?
From my point of view, the main idea is try to identify the maximum instantiation/update/delete request can support the mano framework. In terms of creating/update/destroy a new ns in parallel (10 /100/1000/+++)? Also the plugins and docker containers SSM FSM FLM with a given resources configuration.
@felipevicens @mpeuster @hadik3r
Ok, together with the comments from Felipe, I can up with the following to start from: http://wiki.sonata-nfv.eu/index.php/Stress_the_mano_framework
Let me know what you think.
Stress the mano framework injecting message through the broker and try to measure the response time and the messages lost.
Job description (tsoenen): This test starts by deploying a test plugin (as docker container), which couples to the message broker. This test plugin will make service deploy calls that will appear to the MANO framework as originating from the Gatekeeper. The test plugin will run different set, it will only make one service deploy request, and measure the time between the call and the response that indicates that the deployment succeeded. In the second set, two service deploy requests will be made at the same time, and for both the test plugin will measure the time between the call and the response. We will run a total of 10 sets, where set X makes X service deploy requests.
The test plugin will measure and output the following things: