kafka-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jonathangordon@newrelic.com <jonathangor...@newrelic.com>
Subject Re: Kafka Streams Session store performance degradation from to
Date Fri, 16 Nov 2018 00:33:24 GMT
On 2018/11/08 00:13:39, "Matthias J. Sax" <matthias@confluent.io> wrote: 
> That is what I try to figure out. I went over the to
> Jiras but found nothing I could point out. There are couple of
> SessionStore related tickets, but none of them should have an effect
> like this.
> To narrow it down, it would be helpful to test with other versions, too.
> Maybe and to see when the issue was introduced.

Done. So far here's what my tests have shown: (the current version we're running) and, the local cache works properly
and we see thread profiles similar to what I posted earlier, where the majority of time is
spent in RockDB and there's no lag. 

Testing with,, 1.1.1, 2.0.0 and 2.0.1 all show us spending the majority
of time in the local cache and we lag considerably:


> Can you also profile v0.10.2.1 so we can compare?

Here's a recent profile for


> > What would you recommend for our next steps? 
> Not sure. If you could help us to track down the issue, that would be
> most helpful so get a fix (and you could run from a SNAPSHOT version to
> get the fix -- not sure if this would be an option for you).

Another developer took a look a the code and he had some thoughts:

"It appears we're scanning an order of magnitude more keys for every call to `findSessions`.
You can see this manifest in the flush logs where version and later will have a billion
hits on the cache in 10 minutes, even though the number of events consumed is only 1M. It
seems like when they made some fixes to make sure all possible windows for a session merge
are found that resulted in having to scan every entry in the cache."

Is there a way for us to refine the cache search so we're not searching the entire key space?

View raw message