Comparison to scylla-rust-driver about cdrs-tokio HOT 19 CLOSED

I managed to get cdrs about 2x faster in that benchmark than the scylla driver. I'll push some improvements after I iron out the API.

from cdrs-tokio.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from cdrs-tokio.

Alright, that makes sense.

We modified their benchmarks to run against cdrs-tokio master instead of the old cdrs-tokio version https://github.com/conorbros/rust-driver-benchmarks
We havent done a deep dive into what is causing the difference in performance though.

from cdrs-tokio.

and tested against Cassandra instead of ScyllaDB

from cdrs-tokio.

I will try to address some performance issues next week.

from cdrs-tokio.

@rukai Ah, ok now I understand what you mean. An easy workaround would be introducing owned values for Query and QueryParameters.

from cdrs-tokio.

In our benchmarks we had three-node cluster (on AWS), with driver application working on a separate machine, with communication over LAN. One node is really uncommon, given that both Scylla and Cassandra excel at horizontal scaling. Moreover, since you admitted that you tweaked the parameters, I think that it would be good to also modify the connection pool for the scylla rust driver to 36.
The session builder for scylla rust driver has a method pool_size (per-node). The default value is 1.

from cdrs-tokio.

Sure, will add such test next week. Unfortunately, I don't have access to multi-node clusters to test such configurations - if you have access to one, I would be grateful for some data.

Since a lot of work is going on with Scylla Rust Driver, we're not ready to make the benchmarks yet. However, when the time comes, we'll put crds-tokio up to a test too.

from cdrs-tokio.

cdrs-tokio is aimed to be a rust equivalent to high-level java drivers. The goal is to make it as configurable as possible, which will suit both personal and enterprise projects. scylla-rust-driver seems to be a simpler alternative, which may be appropriate for some projects, but lack features for other.

Out of curiosity - do you know which parts are slower? Since the new version is not published yet, there's still chance for optimization.

from cdrs-tokio.

Interesting - such stable numbers could indicate there's a lock somewhere blocking high concurrency. I thought I got rid of those while removing bb8.

from cdrs-tokio.

After looking at their protocol implementation I realised they use lifetimes in their protocol types to avoid a lot of allocations. This probably is the source of a lot of their speedups but lifetimes also probably mean we can't use the protocol for our project

from cdrs-tokio.

@rukai why can't you use lifetimes in your project? That doesn't make sense to me. You can query with String in the scylla-rust-driver. What are you missing?

from cdrs-tokio.

we need to pass the parsed protocol data across threads, afaik this is impossible if the types contain lifetimes.
The project itself is: https://github.com/shotover/shotover-proxy

from cdrs-tokio.

@rukai I am sure that if you have a non-compiling example code for the scylla-rust-driver, we can make it work

from cdrs-tokio.

I believe this is a fundamental part of how rust works.
Consider this example which doesnt and shouldnt compile:

struct Foo<'a> {
    foo: &'a i32,
}

fn main() {
    let value = 2i32;
    let foo = Foo { foo: &value };
    let mutex = std::sync::Mutex::new(foo);
    let arc = std::sync::Arc::new(mutex);
    std::thread::spawn(move || {
        let lock = arc.lock().unwrap();
        println!("{}", lock.foo);
    });
}

An example of a scylla type that has lifetimes that I want to send across threads is https://docs.rs/scylla/0.3.1/scylla/frame/request/query/struct.Query.html

However...
Now that i'm thinking about this again, its possible this is actually a non-issue due to the scylla types being transformed into types specific to the project before being sent over threads.
I'll have to investigate this further.

from cdrs-tokio.

I've published some performance benchmarks in README. CDRS seems to be now one of the fastest options, depending on configuration.

from cdrs-tokio.

Hey @krojew, would you mind sharing exact setup you used for making the benchmarks, with machine configurations, cluster setup, and code used for the benchmarks?

I'm asking because on the Scylla Rust driver benchmarks, it can be seen that there is a big variance of results between different drivers (even taking aside Scylla Rust driver and CDRS), while yours are all-in-all rather similar (the ratio of times doesn't exceed 2). Perhaps there's something wrong in Scyllas' benchmark setup, or in yours.

from cdrs-tokio.

@enedil I'm running the linked benchmark suite (https://github.com/conorbros/rust-driver-benchmarks) against a single cassandra node (latest image) on Ubuntu 21.10 with i9-7980xe with 32gb ram. The test code is exactly the same with the exception of additional CDRS test having a bigger connection pool (36 vs 1).

from cdrs-tokio.

Sure, will add such test next week. Unfortunately, I don't have access to multi-node clusters to test such configurations - if you have access to one, I would be grateful for some data.

from cdrs-tokio.