I cant see your profiler image so I may be missing something. I remember looking at this in past too. At least with 3.x version of java client the stream ids are reused as released so low volume apps wont have much overhead and highly concurrent ones it prevents allocating 20-100k objs/sec. I think it's something that actually is nuanced on usecase and client and not a straight forward good or bad change. Have you tried benchmarking allocations with newing on each request vs caching by streamid per connection?
Another improvement may be removing the need for the QueryState all together since it doesn't really represent much over being a ClientState wrapper. Or creating an immutable common state thats reused for non-tracing queries per clientstate/connection. Chris On Thu, May 28, 2020 at 11:22 AM Dmitry Konstantinov <netud...@gmail.com> wrote: > Hello, > Could you please help to understand the purpose of a particular part of > code in Cassandra > codebase: org.apache.cassandra.transport.ServerConnection#getQueryState > > https://github.com/apache/cassandra/blob/cassandra-3.11.6/src/java/org/apache/cassandra/transport/ServerConnection.java#L46 > > I noticed it originally in a profiler output: > [image: image.png] > For each CQL connection we have here cached QueryState instances per each > streamId value. This map is only dropped/garbage collected when > ServerCollection is released. > Can we just create a new QueryState for each request? > > Regards, > Dmitry > -- > Dmitry Konstantinov >
