[
https://issues.apache.org/jira/browse/CASSANDRA-13530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16259253#comment-16259253
]
Jason Brown edited comment on CASSANDRA-13530 at 11/20/17 1:51 PM:
-------------------------------------------------------------------
Update on testing: it seems like periodic mode doesn't test {{CommitLogTest}}
very well in the current state of things. As the existing test only exercised
{{batch}} mode, and given the scope of this ticket is to add {{group}} mode, I
propose to ignore (not commit) the {{PeriodicCommitLogTest}} and save that for
a followup ticket as it's slightly outside the scope of the current ticket.
I'll commit {{BatchCommitLogTest}} and {{GroupCommitLogTest}} to preserve the
existing test for batch and add the test for group. wdyt, [~aweisberg]?
{{CommitLogStressTest}} began to timeout in circleci because each {{@Test}}
method tested all configuration (compression, encryption, plain) and mode
variants (periodic, batch, and group). I refactored it to be a
{{@Parameterized}} test class, like {{CommitLogTest}}, and that didn't help.
What did fix it was upping the {{test.long.timeout}} in the {{build.xml}} to 15
minutes from 10, as the timeouts apply to the test class as a whole, not
individual test methods. I can revert the refactor and just leave the build
file change on commit, or we can keep both as the refactor tidied up a few
things in that test class (purely subjective statement) - wdyt?
was (Author: jasobrown):
Update on testing: it seems like periodic mode doesn't test {{CommitLogTest}}
very well in the current state of things. As the existing test only exercised
{{batch}} mode, and given the scope of this ticket is to add {{group}} mode, I
propose to ignore (not commit) the {{PeriodicCommitLogTest}} and save that for
a followup ticket as it's slightly outside the scope of the current ticket.
I'll commit {{BatchCommitLogTest}} and {{GroupCommitLogTest}} to preserve the
existing test for batch and add the test for group. wdyt, @Ariel?
{{CommitLogStressTest}} began to timeout in circleci because each {{@Test}}
method tested all configuration (compression, encryption, plain) and mode
variants (periodic, batch, and group). I refactored it to be a
{{@Parameterized}} test class, like {{CommitLogTest}}, and that didn't help.
What did fix it was upping the {{test.long.timeout}} in the {{build.xml}} to 15
minutes from 10, as the timeouts apply to the test class as a whole, not
individual test methods. I can revert the refactor and just leave the build
file change on commit, or we can keep both as the refactor tidied up a few
things in that test class (purely subjective statement) - wdyt?
> 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: GuavaRequestThread.java, MicroRequestThread.java,
> groupAndBatch.png, groupCommit22.patch, groupCommit30.patch,
> groupCommit3x.patch, groupCommitLog_noSerial_result.xlsx,
> groupCommitLog_result.xlsx
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
