[
https://issues.apache.org/jira/browse/FLINK-23456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17411001#comment-17411001
]
Anton Kalashnikov commented on FLINK-23456:
-------------------------------------------
[~xtsong], sorry for the delay, I have finished with this ticket.
In general, the result looks good. In the case of throttling on the sink, the
throughput is slightly less for buffer debloat than without it(approx. 1%)
which is ok. But in the case of the throttling on the source, the throughput
for some cases(ex. emulation of the window function) could be dropped by 5%
which requires further investigation. But in all cases, the checkpoint time
remains stable and equal to configured one which was our target.
In conclusion, I think "Buffer debloat" feature works as expected. But one more
investigation for future improvement is
required(https://issues.apache.org/jira/browse/FLINK-23974)
> Manually test on cluster
> ------------------------
>
> Key: FLINK-23456
> URL: https://issues.apache.org/jira/browse/FLINK-23456
> Project: Flink
> Issue Type: Sub-task
> Reporter: Anton Kalashnikov
> Assignee: Anton Kalashnikov
> Priority: Blocker
> Labels: release-testing
> Fix For: 1.14.0
>
>
> Test different jobs:
> * a job with static throughput *(must work for successful MVP)*
> * a job with gracefully varying load (sinus shape load?) *(should work for
> successful MVP)*
> * a job with erratic load (emulating evil window operator firing) *(would be
> nice to work for MVP)*
> Test on cluster all jobs and check if/how buffer size adjustment is not
> erratic.
> Verify our final goals:
> * that aligned checkpoint time in back pressured jobs is reduced to sane
> values (roughly {{numberOfExchanges * configuredBufferedDataTime * 2}})
> * check if our changes affected the throughput or not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
