cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-11070) Dispatcher.Flusher's control has duplicated/conflict control
Date Wed, 27 Jan 2016 10:27:39 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-11070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118992#comment-15118992
] 

Benedict edited comment on CASSANDRA-11070 at 1/27/16 10:27 AM:
----------------------------------------------------------------

It is not >10us vs >20us; it is n ~>= 10us, and choosing between n and 2n; on some
systems under high load n could be significantly greater than 10us, perhaps 100us, perhaps
1ms; making it twice n is potentially worse than just adding 10us.

In general, this code is pretty critical to the behaviour of the system.  The current behaviour
was chosen somewhat arbitrarily by me, but it has been fairly thoroughly tested.  With sufficient
testing a different arbitrary behaviour would be fine.

I would personally tend towards simply always flushing either on the second run, if we were
to aim for simplicity; possibly with a zero delay (so that it just runs at the end of a natural
batch), as this is less work, more responsive, and in all likelihood the main benefit is from
batching the natural groupings of messages.

I also, however, don't think this guard is a meaningful contributor to complexity in the codebase,
and that we've already spent more time discussing the _guard_ than it deserves.  However,
analysis of the client batching and improvements to it are central to system behaviour, so
further research is obviously welcomed.  Since this ticket is discussing duplicated behaviour
which is demonstrably absent, I'm closing as Not A Problem


was (Author: benedict):
It is not >10us vs >20us; it is n ~>= 10us, and choosing between n and 2n; on some
systems under high load n could be significantly greater than 10us, perhaps 100us, perhaps
1ms; making it twice n is potentially worse than just adding 10us.

In general, this code is pretty critical to the behaviour of the system.  The current behaviour
was chosen somewhat arbitrarily by me, but it has been fairly thoroughly tested.  With sufficient
testing a different arbitrary behaviour would be fine.

I would personally tend towards simply always flushing either on the second run, if we were
to aim for simplicity; possibly with a zero delay (so that it just runs at the end of a natural
batch), as this is less work, more responsive, and in all likelihood the main benefit is from
batching the natural groupings of messages.

I also, however, don't think this guard is a meaningful contributor to complexity in the codebase,
and that we've already spent more time discussing the _guard_ than it deserves.  However,
analysis of the client batching and improvements to it are central to system behaviour, so
further research is obviously welcomed.  Since this ticket is discussing duplicated behaviour
which is demonstrably absent, I'm closing as Won't Fix.

> Dispatcher.Flusher's control has duplicated/conflict control
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-11070
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11070
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Streaming and Messaging
>            Reporter: fujian
>              Labels: performance
>         Attachments: 0001-fix-CASSANDRA-11070.patch
>
>
> org.apache.cassandra.transport.Message.Dispatcher.Flusher
> remove duplicated control for flush message control …
> Motivation:
> the !doneWork's control is duplicated and confused with runsSinceFlush > 2
> if on the first run:the queue size is 20
> donework will be set to true and not do flush due to the size<50 and runsSinceFlush<2.
> if on the second run. the queue size is 0,
> donework will be reset to false and not set to true due to no new items in queue, but
the flush will be triggered due to:
>   if (!doneWork || runsSinceFlush > 2 || flushed.size() > 50)
> now the runsSinceFlush is 2. so in actual, its function is similar with runsSinceFlush>1.
> so it is no need to keep it so that the code is confused and duplicated.
>               
> Modifications:
> remove it
> Result:
> after remove it, it will more clear and no confused.
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message