-
Notifications
You must be signed in to change notification settings - Fork 3
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
Implement performance tests #9
Comments
I just thought - since we anyway is going to integrate it into Codex and it has its own datastore backends, it will be better to implement performance tests in Codex so it can be used for all backends |
I wouldn't do that. Specific performance tests that concern codex should be placed there, but anything that is specific to the datastore should be part of this repo. |
Let me say it other way. We don't need now perftests of nim-datastore itself. What we really, badly need is perftests of Codex backends, and sqlite one in the first place. So, once nim-datastore will start to work with Codex, writing perftests for sqlite backend of blockstore will became the next priority task. |
It doesn't make sense to write sql specific tests in Codex, since it has it's own abstraction (the blockstore) already, but it does make sense to have sql specific perf tests along side the sql backend. Really, we need both, except that here they would be more generic, hopefully including several datatypes and the interface should support this multiple types, while in Codex they would be specific to blocks/chunks/etc... |
I don't mean any sql-specific or sqlite-specific perftests. In both repositories perftests can be written against generic API and then run against instances of each store type. Currently low performance of file-based blockstore is most serious performance issue in Codex, so I want to have perftests in Codex with scenarios typical for Codex application - such as putting a million of 64 KB data blocks to the store and then retrieving them back. By running this test against sqlite backend we will see what level of performance we can expect for storing in this backend real amounts of data (an order of 1 TB). |
I'm not disagreeing, like I said we should have both, but this library should be standalone catering to a wider audience, not even potentially aware of codex, so bringing codex specifics here is a bit irrelevant to this particular library. |
ok, so this task is low-priority like everything we don't immediately need for Codex |
Should help to determine best options for use with
Datastore
impls in relation to concrete use cases, e.g. Codex.The text was updated successfully, but these errors were encountered: