joao-r-reis commented on issue #845: URL: https://github.com/apache/cassandra-gocql-driver/issues/845#issuecomment-3555312561
So after you made the queries preparable did you double check to see if you're still seeing cache evictions or is the size of the cache stable? If you're misuing prepared statements then you will run into the issue of the cache constantly hitting the limit and having to evict statements. If you're sure you're not seeing cache evictions now and you're still not happy with the performance of the cache then the only thing that would maybe help is using a cache that isn't limited by the performance of `sync.Mutex` but we'd really need to see some data to see that the mutex is the bottleneck. And even if that was the case then we would probably just make it an interface and allow the user to provide a custom cache implementation because I don't think this is a problem that enough users will face that would justify adding an external dependency for a LRU cache library like `maypok86/otter` (maybe I could see it on a separate package). It could also just be that the reason gocql is slower than java for your workload is unrelated to the prepared cache which is another reason why we'd like to see some data suggesting that changing the cache or even allowing statements to be unprepared would solve anything. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
