[
https://issues.apache.org/jira/browse/CASSANDRA-13530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036648#comment-16036648
]
Yuji Ito commented on CASSANDRA-13530:
--------------------------------------
I measured latency by fixing concurrency at 256 and using a Guava rate limiter
to generate requests at a fixed rate ([^GuavaRequestThread.java]).
The environment and Cassandra configuration are the same as before.
The latency of GroupCommitLog is less than half of BatchCommitLog for SELECT
and UPDATE.
I attached the result file ([^groupCommitLog_result.xlsx]) including histograms
of latency.
- SELECT - Batch 2ms
||Throughput [ops]||Avg. latency [ms]||
|100|2.6|
|200|12.6|
|500|20.3|
|1000|27.0|
- SELECT - Group 10ms
||Throughput [ops]||Avg. latency [ms]||
|100|8.1|
|200|8.3|
|500|9.3|
|1000|26.2|
- SELECT - Group 15ms
||Throughput [ops]||Avg. latency [ms]||
|100|10.8|
|200|11.0|
|500|13.5|
|1000|15.0|
- UPDATE - Batch 2ms
||Throughput [ops]||Avg. latency [ms]||
|100|86.1|
|200|108.6|
|500|121.6|
|1000|133.9|
- UPDATE - Group 10ms
||Throughput [ops]||Avg. latency [ms]||
|100|37.8|
|200|104.0|
|500|118.7|
|1000|131.4|
- UPDATE - Group 15ms
||Throughput [ops]||Avg. latency [ms]||
|100|54.6|
|200|56.2|
|500|115.2|
|1000|122.1|
> GroupCommitLogService
> ---------------------
>
> Key: CASSANDRA-13530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13530
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Yuji Ito
> Assignee: Yuji Ito
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
> Attachments: groupCommit22.patch, groupCommit30.patch,
> groupCommit3x.patch, groupCommitLog_result.xlsx, GuavaRequestThread.java,
> MicroRequestThread.java
>
>
> I propose a new CommitLogService, GroupCommitLogService, to improve the
> throughput when lots of requests are received.
> It improved the throughput by maximum 94%.
> I'd like to discuss about this CommitLogService.
> Currently, we can select either 2 CommitLog services; Periodic and Batch.
> In Periodic, we might lose some commit log which hasn't written to the disk.
> In Batch, we can write commit log to the disk every time. The size of commit
> log to write is too small (< 4KB). When high concurrency, these writes are
> gathered and persisted to the disk at once. But, when insufficient
> concurrency, many small writes are issued and the performance decreases due
> to the latency of the disk. Even if you use SSD, processes of many IO
> commands decrease the performance.
> GroupCommitLogService writes some commitlog to the disk at once.
> The patch adds GroupCommitLogService (It is enabled by setting
> `commitlog_sync` and `commitlog_sync_group_window_in_ms` in cassandra.yaml).
> The difference from Batch is just only waiting for the semaphore.
> By waiting for the semaphore, some writes for commit logs are executed at the
> same time.
> In GroupCommitLogService, the latency becomes worse if the there is no
> concurrency.
> I measured the performance with my microbench (MicroRequestThread.java) by
> increasing the number of threads.The cluster has 3 nodes (Replication factor:
> 3). Each nodes is AWS EC2 m4.large instance + 200IOPS io1 volume.
> The result is as below. The GroupCommitLogService with 10ms window improved
> update with Paxos by 94% and improved select with Paxos by 76%.
> h6. SELECT / sec
> ||\# of threads||Batch 2ms||Group 10ms||
> |1|192|103|
> |2|163|212|
> |4|264|416|
> |8|454|800|
> |16|744|1311|
> |32|1151|1481|
> |64|1767|1844|
> |128|2949|3011|
> |256|4723|5000|
> h6. UPDATE / sec
> ||\# of threads||Batch 2ms||Group 10ms||
> |1|45|26|
> |2|39|51|
> |4|58|102|
> |8|102|198|
> |16|167|213|
> |32|289|295|
> |64|544|548|
> |128|1046|1058|
> |256|2020|2061|
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
