Please continue using Ignite.NET thick client until we release partition-awareness for the thin one. That feature has been already developed and to be released in Ignite 2.8.
Presently, the thin client sends all the request via the proxy which is one of the server nodes it's connected to. While the thick client always goes to a node that keeps a key. The proxy is a bottleneck and that's why you see such a performance drop. - Denis On Thu, Aug 22, 2019 at 11:49 PM Eduard Llull <edu...@llull.net> wrote: > Hello everyone, > > We have just developed a gRPC service in .NET core that performs a bunch > of cache gets for every RPC. We've been using the Apache.NET nuGet starting > the Ignite node in client mode (thick client) but we just changed it to use > the thin client and we see much much worse response times: from 4ms average > and 15ms 95th percentile, to 21ms average and 86ms 95th percentile, but the > times get event worse under load: peaks of 115ms average, 1s 95th > percentile. > > We were expecting some level of degradation in the response times when > changeing from the thick to the thin client but not as much. In fact, > trying to reduce the impact, we've deployed a Ignite node in client mode on > every host where we have our gRPC service deployed and the gRPC service > connects to the local Ignite node. > > The gRPC service receives several tens of concurrent requests when under > load, but we instantiate one single ApacheClient (Ignition.StartClient()) > shared by all the threads that are serving the RPC requests. I've seen in > the Java Thin Client documentation ( > https://apacheignite.readme.io/docs/java-thin-client-initialization-and-configuration#section-multithreading) > the following: > > Thin client is single-threaded and thread-safe. The only shared resource > is the underlying communication channel, and only one thread reads/writes > to the channel while other threads are waiting for the operation to > complete. > Use multiple threads with thin client connection pool to improve > performance > > Presently thin client has no feature to create multiple threads to improve > throughput. You can create multiple threads by getting thin client > connection from a pool in your application to improve throughput. > > But there is no such warning in the .NET thin client documentation ( > https://apacheignite-net.readme.io/docs/thin-client). > > Is it possible that the huge increase in the reponse times comes from > contention when multiple gRPC threads are using the same thin client (thus, > the same ClientSocket) to communicate with the cluster? > > In the mean time we will use a thin client pool as recommended in the Java > documentation to see if it improves the performance. > > > Thank you very much. >
