You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is observed that the Beam's implementation is less performant than the Dataflow one, which is as expected. However, the generic expectation is that the performance to be reasonable on other runners and we expect the SDK to be in production grade, which appears not the cases currently.
For example, there are reports of high ack and sent message counts when read from PubSub. It's not the high throughput use case. It's only 1 message per second. Yet, the number of "acks" is 14 times the number of published messages. And the number of "sent" is 6 times the number of published messages.
As a first step we should investigate why the messages are ack and published multiple times on, for example, the Flink runner.
Issue Priority
Priority: 2 (default / most bugs should be filed as P2)
Issue Components
Component: Python SDK
Component: Java SDK
Component: Go SDK
Component: Typescript SDK
Component: IO connector
Component: Beam YAML
Component: Beam examples
Component: Beam playground
Component: Beam katas
Component: Website
Component: Spark Runner
Component: Flink Runner
Component: Samza Runner
Component: Twister2 Runner
Component: Hazelcast Jet Runner
Component: Google Cloud Dataflow Runner
The text was updated successfully, but these errors were encountered:
What happened?
This issue is used to track Beam PubSubIO performance issue.
Per https://cloud.google.com/dataflow/docs/concepts/streaming-with-cloud-pubsub Dataflow runner uses an internal implementation of PubSubIO. While the Beam's open-sourced PubsubIO is used for Direct Runner, Flink Runner, etc
It is observed that the Beam's implementation is less performant than the Dataflow one, which is as expected. However, the generic expectation is that the performance to be reasonable on other runners and we expect the SDK to be in production grade, which appears not the cases currently.
For example, there are reports of high ack and sent message counts when read from PubSub. It's not the high throughput use case. It's only 1 message per second. Yet, the number of "acks" is 14 times the number of published messages. And the number of "sent" is 6 times the number of published messages.
As a first step we should investigate why the messages are ack and published multiple times on, for example, the Flink runner.
Issue Priority
Priority: 2 (default / most bugs should be filed as P2)
Issue Components
The text was updated successfully, but these errors were encountered: