I guess futures::future::result will probably work fine. Also the example code in my former comment works fine as future at the compile-time. But the point I want to point out most is that we would be probably blocking io-read.
For example, I’m actually making such a batch like the following, in case of making heavy reads cuncurrently (more than 10K reads/sec continuousely), we can make only 3-5K reads/sec with aerospike-client-rust, although the same kind of batch ( which is written by golang, with concurrently io-read with goroutine) is performing around 12K reads/sec.
In my enviroment, golang’s batch can finish to read about 5M records in 5minutes, while rust-lang’s takes 3 to 5 times longer.
(I’m testing both batches on GCP n1-highmem-2 with 2Core vCPU and 13 GB memory)
Now, I believe rust-lang is potentially high performance more than or equal to golang.
I found your code above using std::net::TcpStream (which would block io, i guess) . We’d better use non-blocking TcpStream ( for example, tokio::net::TcpStream), don’t we?.
You are right, the client is using blocking I/O. Not to make excuses, but 2 years ago, when the client was developed, Rust’s support for async I/O wasn’t very mature yet, so the client only supports sync I/O. And despite initial interest in a Rust client we have not actually seen much usage of the client since then. We also believe that Rust has the potential to perform as good or even better than the Go client, but a lot more time and effort have been poured into optimizing the Go client (as well as the C, C# and Java clients).
Are you trying to make a decision whether to use the Rust or Go client? Or do you want to use the Rust client but need better performance than the client can currently support? What are your specific requirements?
Now I understand the situation and the needs of 2 years ago to now. @Jan
My purpose is not to decide whether to adopt Go or Rust client. Rather, I want to adopt Rust and I just expect better performance (especially not blocking I/O).
I’m a tech-lead at a startup company, and I’m aggressively trying to adopt Rust for new products in these days. Almost all client libraries I need are compatible with non-blocking I/O (eg rust-rdkafka, clickhouse-rs, elastic-rs).
If aerospike-client-rust becomes non-blocking I/O, it will help to adopt Rust throughout a new product (not just the batch process I previously commented on).
It is a proposal, but if possible, could you modify the aerospike-client-rust? I am not in a hurry, it may take a long time if necessary.
(I hope I would like to be able to send a pull-request by myself, but my knowledge on aerospike-server is not high).
Hi @shuucream2011 very sorry for the late response. Like Jan said, we haven’t received much interest in the Rust client and so our developers have to focus on the more used clients. If you do have (and it sounds like you do have) the rust knowledge to rework the blocking io we can help answer questions on the Aerospike side. A pull request would be very warmly welcome.