[
https://issues.apache.org/jira/browse/FLINK-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265130#comment-16265130
]
Dian Fu edited comment on FLINK-8144 at 11/24/17 10:19 AM:
-----------------------------------------------------------
{{AbstractKeyedCEPPatternOperator}} has similar logic as
{{RowTimeUnboundedOver}}. As described in FLINK-8106, we find that the
performance is very bad under the current logic for
{{AbstractKeyedCEPPatternOperator}}. The throughput can increase from 10+ tps
to about 3500 tps for one operator in the case of RocksDBStateBackend after
optimizing the timer logic. I think the optimization should also apply to
{{RowTimeUnboundedOver}}.
BTW: the watermark we use in the CEP use case is
{{AssignerWithPunctuatedWatermarks}}. It will generate one watermark for every
input element.
was (Author: dian.fu):
{{AbstractKeyedCEPPatternOperator}} has similar logic as
{{RowTimeUnboundedOver}}. As described in FLINK-8106, we find that the
performance is very bad under the current logic for
{{AbstractKeyedCEPPatternOperator}}. The throughput can increase from 10+ tps
to about 3500 tps for one operator in the case of RocksDBStateBackend. I think
the optimization should also apply to {{RowTimeUnboundedOver}}.
> Optimize the timer logic in RowTimeUnboundedOver
> ------------------------------------------------
>
> Key: FLINK-8144
> URL: https://issues.apache.org/jira/browse/FLINK-8144
> Project: Flink
> Issue Type: Bug
> Components: Table API & SQL
> Reporter: Dian Fu
> Assignee: Dian Fu
> Fix For: 1.5.0
>
>
> Currently the logic of {{RowTimeUnboundedOver}} is as follows:
> 1) When element comes, buffer it in MapState and and register a timer at
> {{current watermark + 1}}
> 2) When event timer triggered, scan the MapState and find the elements below
> the current watermark and process it. If there are remaining elements to
> process, register a new timer at {{current watermark + 1}}.
> Let's assume that watermark comes about 5 seconds later than the event on
> average, then we will scan about 5000 times the MapState before actually
> processing the events.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
