You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Alan Conway (JIRA)" <ji...@apache.org> on 2018/08/06 22:16:00 UTC
[jira] [Commented] (PROTON-1910) Profiling indicates that cgo
becomes a bottleneck during scale testing of electron
[ https://issues.apache.org/jira/browse/PROTON-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570852#comment-16570852 ]
Alan Conway commented on PROTON-1910:
-------------------------------------
Thanks for this observation. Are you seeing the overhead in NewMessage() itself (which only makes a single C call) or could it be under the Marshal() call in NewMessageWith()? Marshalling is quite chatty with C, we might be able to bundle up some of the C calls to reduce the overhead.
> Profiling indicates that cgo becomes a bottleneck during scale testing of electron
> ----------------------------------------------------------------------------------
>
> Key: PROTON-1910
> URL: https://issues.apache.org/jira/browse/PROTON-1910
> Project: Qpid Proton
> Issue Type: Bug
> Components: go-binding
> Affects Versions: proton-c-0.24.0
> Reporter: Aaron Smith
> Assignee: Alan Conway
> Priority: Major
>
> While performing scale testing, detailed profiling of Go test clients showed that >95% of the execution time can be devoted to the cgo call. The issues seems to be related on sends to the NewMessage() call. For receives, the bottleneck is both NewMessage() and the call to actually receive the message.
>
> This behavior is not unexpected as CGO is a well-known bottleneck. Would it be possible to have a NewMessage() call that return multiple messages and a recv call that took an "At most" argument. i.e. recv(10) would receive 10 or fewer messages that might be waiting in the queue. Also, it would be nice to be able to trade latency for throughput in that the callback wasn't triggered until N messages were recieved (with timeout)....
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org