You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm interested in learning more about the performance of jetcd, specifically things like e.g. the maximum number of parallel TXN with a handful of PUT over a relatively large key space per sec.
I'm assuming that there already are performance tests on etcd itself (where, BTW?), and just doing the same through jetcd should lead to similar results - but think it's interesting to anyway exercise it here in this project also, through the JVM and this projects code - agreed? (And it could, later, also be fun to performance profile such a test to see if there are any low hanging fruit obvious performance hot spots anywhere in code in this project...)
I was anyway hoping to do something like this as part of the https://github.com/vorburger/opendaylight-etcd POC some day (after first figuring out the equivalent number of expected size of data and how much change per minute in another existing data store implementation, which that project proposes to replace; to then be able to compare the numbers and see if we have a match or are miles apart), but I guess any code using purely jetcd performance stress testing would best be contributing to this project directly instead.
Please do shout by replying here if this already exists (or is a stupid idea).
The text was updated successfully, but these errors were encountered:
I'm interested in learning more about the performance of jetcd, specifically things like e.g. the maximum number of parallel TXN with a handful of PUT over a relatively large key space per sec.
I'm assuming that there already are performance tests on etcd itself (where, BTW?), and just doing the same through jetcd should lead to similar results - but think it's interesting to anyway exercise it here in this project also, through the JVM and this projects code - agreed? (And it could, later, also be fun to performance profile such a test to see if there are any low hanging fruit obvious performance hot spots anywhere in code in this project...)
I was anyway hoping to do something like this as part of the https://github.com/vorburger/opendaylight-etcd POC some day (after first figuring out the equivalent number of expected size of data and how much change per minute in another existing data store implementation, which that project proposes to replace; to then be able to compare the numbers and see if we have a match or are miles apart), but I guess any code using purely jetcd performance stress testing would best be contributing to this project directly instead.
Please do shout by replying here if this already exists (or is a stupid idea).
The text was updated successfully, but these errors were encountered: