question

@pranali.khanna101994_189965 Apache Cassandra uses a traditional, staged, event-driven architecture (SEDA). DSE 5.1 Architecture used multiple threads per task and hence the threads needed coordination and context switching. Also events were synchronous. That is the reason adding more cpu cores did result in contentions and slowdowns.

In DSE 6.0, major architecture changes were introduced. Coordination free, thread per core and asynchronous operation for reads, writes, and other tasks were introduced.

Please refer to our documentation for more details and performance comparisons at DSE 6.0 Architecture

Open-source Apache Cassandra uses the traditional staged event-driven architecture (SEDA) where tasks are executed by threads synchronously. This has worked well for quite some time now but we know that the synchronous nature of the architecture can lead to extremely high context-switching during peak loads which can cause resource contention and degrades the performance of the nodes.

In DSE 6.0, we released a new feature called Advanced Performance. Under the hood is a thread-per-core (TPC) architecture which significantly improves read and write performance with asynchronous IO -- read and write requests are no longer synchronous to remove thread contention and keeps IO threads processing.

This feature uses the Linux kernel LibAIO access library libaio, AIO being short for asynchronous input/output. This means that it only works when the libaio package is installed on the nodes. Otherwise, reads and writes are done synchronously as before.

For more info, see the blog post DSE Advanced Performance: Apache Cassandra™ Goes Turbo. Cheers!