utking commented on issue #845: URL: https://github.com/apache/cassandra-gocql-driver/issues/845#issuecomment-3555380565
@joao-r-reis Yes, we did check and we don't see cache flushes often anymore (they do occur, but very rarely). The cache size (from the Cassandra DEBUG logs) seems stable. This, in my opinion, shows that we are not misusing the cache as we did issuing raw statements in the start of the switch. It's not that we are not happy with the performance of the cache. It's that with the [seemingly] stable cache we still see high CPU usage and read/write volumes and latency. I am not sure it is attributable to the prepared statements cache. I am also not sure why `sync.Mutex` would be the issue since we do not observe any load (or otherwise) issues with the proxy using the driver; we observe them only on the Cassandra cluster nodes that the proxy talks to. Go driver being slower than the Java one - we compared the two driver versions on the very same [production] workload. The processing time for workers talking to Cassandra through the proxies did not change. If the Go driver is slow, I don't really see how/what to check to confirm that. I want to agree that prepared statement are a better way to go, but if it turns out they are causing the issue, I would prefer them conditional instead. We tried protocols v3 (originally, because it was used with the Java version) and v4 (to check if anything will change; nothing did). I did prepare the v2.0.0-based version to try protocol v5 when we have a chance (scheduled in the end of December 2025), but I saw nothing in the changelog that would suggest it should improve the situation. Also, as it was suggested earlier, I probably will try a custom fork with the `shouldPrepare` being disabled - just to finally test the assumption that it is the unconditional prepared statements that cause the LoadAverage spikes under heavy workloads. Thanks for your prompt response! -- 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]
