[
https://issues.apache.org/jira/browse/CASSANDRA-13530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16171928#comment-16171928
]
Ariel Weisberg commented on CASSANDRA-13530:
--------------------------------------------
I've run into a different justification for this change. Reducing P/E cycles on
SSDs that don't have a non-volatile write cache sitting in front.
So we don't need to justify having this functionality with just performance and
batch would still do the wrong thing even if it was faster.
Just a heads up this can only go into trunk. 2.2, 3.0, and 3.11 are bug fix
only. So in 2.2, 3.0 and 3.11 we could fix batch by ignoring the value
commitlog_sync_batch_window_in_ms and updating the documentation in
cassandra.yaml as well as mentioning that it's deprecated.
So on to reviewing the details.
* This needs a unit test exercising the new commit log configuration, as well
as acceptable and not acceptable configuration values (0, negative, largest
value, smallest value)
* How about we fix commitlog_sync_batch_window_in_ms by 100% ignoring the
value. We can't change the configuration behavior of batch (people won't update
their config) but we can fix the broken implementation. Also mark it as
deprecated in the docs so we can remove it later.
* Then use commitlog_sync_group_window_in_ms to configure the batch commit log
service. If unset, batch works the way it does today. If set then it implements
the fixed grouping behavior. Document in cassandra.yaml appropriately.
* Alternatively add a new commit log implementation (group) that can do both
group and batch and deprecate batch commit log. Eventually we will converge on
one implementation with consistent configuration naming.
> 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: groupAndBatch.png, groupCommit22.patch,
> groupCommit30.patch, groupCommit3x.patch,
> groupCommitLog_noSerial_result.xlsx, 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.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
