add fallout smoke test #423
Conversation
| @@ -0,0 +1,133 @@ | |||
| # region setup | |||
There was a problem hiding this comment.
should we separate tests info folders? fallout/smoke-test/..
There was a problem hiding this comment.
Will not do, following same as in the /nosqlbench/ directory..
| - connections=30 | ||
| - docscount={{docs_count}} | ||
|
|
||
| - |
There was a problem hiding this comment.
should I add support for sequential execution?
fallout/smoke-test-fallout.yaml
Outdated
| ops: | ||
| - op: find-one-id | ||
| - op: find-one-by-city | ||
| - op: find-multi-by-married-name-exists | ||
| - op: find-multi-by-married-name-exists-with-projection | ||
| - op: find-multi-find-by-gender-sort-by-name | ||
| - op: find-by-name-newest-and-update-city | ||
| - op: delete-one-id | ||
| - op: find-one-id-and-replace-upsert | ||
| - op: count-all | ||
| - op: count-by-gender |
There was a problem hiding this comment.
@vkarpov15 We agreed to ask you about a more realistic scenario structure.. Currently we run these in parallel, and each weights the same, so each op contributes with 10%.. Also it would be great if you have any additions to this, some operation we should include, etc?
There was a problem hiding this comment.
@ivansenic it might be helpful to add insert operations, and maybe some more update operations. In particular, an updateMany. However, Mongoose apps currently tend to be read heavy, so this isn't too far off.
I think we should take a look at the results of this scenario, because this scenario covers a good range of features. If there are performance issues, it's worth investigating.
In the future, we can add scenarios that are more in line with basic apps, like simulating what happens with our sample apps under load.
There was a problem hiding this comment.
@vkarpov15 Thanks for the suggestions, good points..
What about the count, is this something that is use din mongoose space a lot? I was thinking we should decrease to one count op only?
There was a problem hiding this comment.
Depends on the app, but many apps that use some sort of pagination also use countDocuments() to calculate the number of documents in the result set. It's not a bad idea to decrease to one count op, but I think it is worth looking into why count causes performance issues, and if there's something we can do to improve it.
There was a problem hiding this comment.
I think @maheshrajamani found one thing that may help improve performance (count(1) instead of count(column)), we'll see how much that helps (fix has been merged).
There was a problem hiding this comment.
- Added update many instead of the count all
- Adapted count and sort ops so that we can control how many docs should be targeted in those ops
What this PR does:
Adds smoke test for Fallout, including the target nosqlbench file
Checklist