You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "Yibo Cai (Jira)" <ji...@apache.org> on 2021/02/22 06:29:00 UTC
[jira] [Commented] (ARROW-10351) [C++][Flight] See if
reading/writing to gRPC get/put streams asynchronously helps performance
[ https://issues.apache.org/jira/browse/ARROW-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288198#comment-17288198 ]
Yibo Cai commented on ARROW-10351:
----------------------------------
Hi [~wesm], [~lidavidm],
I'm planning to investigate if gRPC async server may improve Flight performance. Would like to know if community is doing similar things to avoid duplicated effort. Thanks.
I see another Jira looks related https://issues.apache.org/jira/browse/ARROW-1009.
> [C++][Flight] See if reading/writing to gRPC get/put streams asynchronously helps performance
> ---------------------------------------------------------------------------------------------
>
> Key: ARROW-10351
> URL: https://issues.apache.org/jira/browse/ARROW-10351
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++
> Reporter: Wes McKinney
> Priority: Major
>
> We don't use any asynchronous concepts in the way that Flight is implemented now, i.e. IPC deconstruction/reconstruction (which may include compression!) is not performed concurrent with moving FlightData objects through the gRPC machinery, which may yield suboptimal performance.
> It might be better to apply an actor-type approach where a dedicated thread retrieves and prepares the next raw IPC message (within a Future) while the current IPC message is being processed -- that way reading/writing to/from the gRPC stream is not blocked on the IPC code doing its thing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)