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/10/11 22:31: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=16647119#comment-16647119 ]
Alan Conway commented on PROTON-1910:
-------------------------------------
This commit implements the strategy outlined above: moving all message encode/decode into the proton goroutine and re-using a single pn_message_t per connection to save some setup time and cache some data structures. I see about 30% improvement in performance with this fix:
4a9f3b98 * PROTON-1910: [go] move message encode/decode to handler thread
The Go client is still slower than I would like compared to the C client, further optimization work is needed.
> 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
> Fix For: proton-c-0.27.0
>
>
> 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