[
https://issues.apache.org/jira/browse/FLINK-16057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116275#comment-17116275
]
Roman Khachatryan commented on FLINK-16057:
-------------------------------------------
I don't the reason.
My first guess was that the benchmark is wrong, but I couldn't spot any issues.
Can you please take a look:
[https://github.com/dataArtisans/flink-benchmarks/pull/62] ?
I also repeated the non-io-benchmark (that generates numbers without reading
files):
{code:java}
old:
"Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit"
"org.apache.flink.benchmark.ContinuousFileReaderOperatorBenchmark.readFileSplit","thrpt",1,30,18193.296713,1288.369575,"ops/ms"
new:
"Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit"
"org.apache.flink.benchmark.ContinuousFileReaderOperatorBenchmark.readFileSplit","thrpt",1,30,12491.844935,165.684694,"ops/ms"
{code}
> Performance regression in ContinuousFileReaderOperator
> ------------------------------------------------------
>
> Key: FLINK-16057
> URL: https://issues.apache.org/jira/browse/FLINK-16057
> Project: Flink
> Issue Type: Bug
> Components: API / DataStream, Runtime / Task
> Affects Versions: 1.11.0
> Reporter: Roman Khachatryan
> Assignee: Roman Khachatryan
> Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After switching CFRO to a single-threaded execution model performance
> regression was expected to be about 15-20% (benchmarked in November).
> But after merging to master it turned out to be about 50%.
>
> One reason is that the chaining strategy isn't set by default in CFRO factory.
> Without that even reading and outputting all records of a split in a single
> mail action doesn't reverse the regression (only about half).
> However, with strategy set AND batching enabled fixes the regression
> (starting from batch size 6).
> Though batching can't be used in practice because it can significantly delay
> checkpointing.
>
> Another approach would be to process one record and the repeat until
> defaultMailboxActionAvailable OR haveNewMail.
> This reverses regression and even improves the performance by about 50%
> compared to the old version.
>
> The final solution could also be FLIP-27.
>
> Other things tried (didn't help):
> * CFRO rework without subsequent commits (removing checkpoint lock)
> * different batch sizes, including the whole split, without chaining
> strategy fixed - partial improvement only
> * disabling close
> * disabling checkpointing
> * disabling output (serialization)
> * using LinkedList instead of PriorityQueue
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
