-
Notifications
You must be signed in to change notification settings - Fork 558
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
chore(benchmarks): add more starters per default #4288
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Sorry this took so long. One question, the make starter
will still start the old single task process?
Yes correct. Actually here seems a commit missing where I adjusted the makefil. I will add this |
To improve our test coverage I added a simple starter and a timer starter. The simple one contains just start event and end event. It is quite interesting to see how the latency behaves on these instances. The timer starter contains a workflow with a timer set to PT1S. Per default we will start all of them to have high load and test that this can be handled by the brokers.
sed -i "s/default/$namespace/g" Makefile | ||
sed -i "s/default/$namespace/g" worker.yaml | ||
sed -i "s/default/$namespace/g" starter.yaml | ||
sed -i "s/default/$namespace/g" Makefile starter.yaml timer.yaml simpleStarter.yaml worker.yaml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't know you could do that 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Me2 😆 found out accidentally 😄
bors r+ |
4288: chore(benchmarks): add more starters per default r=Zelldon a=Zelldon ## Description To improve our test coverage I added a simple starter and a timer starter. The simple one contains just start event and end event. It is quite interesting to see how the latency behaves on these instances and to just introduce some more load to the broker. The timer starter contains a workflow with a timer set to PT1S. Per default we will start all of them to have high load and test that this can be handled by the brokers without any problems. ![metrics](https://user-images.githubusercontent.com/2758593/78907407-f1d6a500-7a80-11ea-82c7-8a5a5a3a1cab.png) ## Further I want to add later also workflow with contain message catch events and a pod which just publishes messages. <!-- Please explain the changes you made here. --> <!-- Which issues are closed by this PR or are related --> # Co-authored-by: Christopher Zell <zelldon91@googlemail.com>
Build failed |
bors r+ |
4288: chore(benchmarks): add more starters per default r=Zelldon a=Zelldon ## Description To improve our test coverage I added a simple starter and a timer starter. The simple one contains just start event and end event. It is quite interesting to see how the latency behaves on these instances and to just introduce some more load to the broker. The timer starter contains a workflow with a timer set to PT1S. Per default we will start all of them to have high load and test that this can be handled by the brokers without any problems. ![metrics](https://user-images.githubusercontent.com/2758593/78907407-f1d6a500-7a80-11ea-82c7-8a5a5a3a1cab.png) ## Further I want to add later also workflow with contain message catch events and a pod which just publishes messages. <!-- Please explain the changes you made here. --> <!-- Which issues are closed by this PR or are related --> # Co-authored-by: Christopher Zell <zelldon91@googlemail.com>
Build failed |
bors r+... |
4288: chore(benchmarks): add more starters per default r=Zelldon a=Zelldon ## Description To improve our test coverage I added a simple starter and a timer starter. The simple one contains just start event and end event. It is quite interesting to see how the latency behaves on these instances and to just introduce some more load to the broker. The timer starter contains a workflow with a timer set to PT1S. Per default we will start all of them to have high load and test that this can be handled by the brokers without any problems. ![metrics](https://user-images.githubusercontent.com/2758593/78907407-f1d6a500-7a80-11ea-82c7-8a5a5a3a1cab.png) ## Further I want to add later also workflow with contain message catch events and a pod which just publishes messages. <!-- Please explain the changes you made here. --> <!-- Which issues are closed by this PR or are related --> # Co-authored-by: Christopher Zell <zelldon91@googlemail.com>
Build failed |
…4288) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Houssain Barouni <146710021+houssain-barouni@users.noreply.github.com>
Description
To improve our test coverage I added a simple starter and a timer starter. The simple one contains just start event and end event. It is quite interesting to see how the latency behaves on these instances and to just introduce some more load to the broker.
The timer starter contains a workflow with a timer set to PT1S. Per default we will start all of them
to have high load and test that this can be handled by the brokers without any problems.
Further
I want to add later also workflow with contain message catch events and a pod which just publishes messages.
Pull Request Checklist
mvn clean install -DskipTests
locally before committing