Repository navigation
Added docs about cf-reactor performance - #3824
Conversation
cd0b96f to
e175475
Compare
Signed-off-by: Victor Moene <victor.moene@northern.tech>
e175475 to
07d68e5
Compare
| **Notes:** | ||
|
|
||
| - Users and packages could not be added or removed fast enough to reach the limit of `cf-reactor`: these figures are lower bounds. | ||
| - Above the limit, `cf-reactor` doesn't lose events: they pile up in the queue and are handled late. |
There was a problem hiding this comment.
Does the queue ever get full? Will you eventually run out of memory?
There was a problem hiding this comment.
No, the queue cannot get full. Yes it will ran out of memory if too many events are coming.
|
|
||
| **Notes:** | ||
|
|
||
| - Users and packages could not be added or removed fast enough to reach the limit of `cf-reactor`: these figures are lower bounds. |
There was a problem hiding this comment.
You could use a fake package module that is faster.
|
Maybe a better way to measure this is: how fast can you setup and execute an empty bundle, and how fast is the "check" for each type. Everything else seems out of our control. E.g., what the then bundle is doing, or how slow the package manager is. Those things are not really cf-reactor limits. |
That's true, but I think real-world performance is what matters to users. |
Clarified what cf-reactor’s performance depends on: the speed of the event type and the speed of the then bundle Showed what then bundle was used for the experiments. Signed-off-by: Victor Moene <victor.moene@northern.tech>
3b99ec3 to
abbe31b
Compare
larsewi
left a comment
There was a problem hiding this comment.
E.g., what the then bundle is doing, or how slow the package manager is. Those things are not really cf-reactor limits.
That's true, but I think real-world performance is what matters to users.
Still feels strange to base the limit of cf-reactor on how fast you can install or uninstall packages. But I guess the notes mention it. So it's fine by me.
No description provided.