Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Definition - Stress the mano framework #230

Open
felipevicens opened this issue Mar 14, 2017 · 4 comments
Open

Definition - Stress the mano framework #230

felipevicens opened this issue Mar 14, 2017 · 4 comments

Comments

@felipevicens
Copy link
Member

felipevicens commented Mar 14, 2017

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:

  • Average deployment time for each set
  • Percentage of satisfied deployment requests
@tsoenen
Copy link
Member

tsoenen commented Mar 20, 2017

Job created.

Next up: Job description.

@tsoenen
Copy link
Member

tsoenen commented Mar 28, 2017

@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) ... )?

@felipevicens
Copy link
Member Author

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.

@tsoenen
Copy link
Member

tsoenen commented Mar 28, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants