[
https://issues.apache.org/jira/browse/PROTON-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573270#comment-16573270
]
Aaron Smith commented on PROTON-1910:
-------------------------------------
A little late... but here are the results for the same setup on the receive
side...
----------------------------------------------------------+-------------
flat flat% sum% cum cum% calls calls% + context
----------------------------------------------------------+-------------
0.73s 37.06% |
github.com/redhat-nfvpe/telemetry-consumers/vendor/qpid.apache.org/electron.(*handler).HandleMessagingEvent
0.53s 26.90% |
github.com/redhat-nfvpe/telemetry-consumers/vendor/qpid.apache.org/proton.(*Engine).Run
0.16s 8.12% |
github.com/redhat-nfvpe/telemetry-consumers/vendor/qpid.apache.org/proton.(*Engine).writeBuffer
0.07s 3.55% |
github.com/redhat-nfvpe/telemetry-consumers/internal/pkg/amqp.(*AMQPServer).start
0.05s 2.54% |
github.com/redhat-nfvpe/telemetry-consumers/vendor/qpid.apache.org/electron.(*ReceivedMessage).acknowledge.func1
0.05s 2.54% |
github.com/redhat-nfvpe/telemetry-consumers/vendor/qpid.apache.org/proton.(*MessagingAdapter).HandleEvent
0.04s 2.03% |
github.com/redhat-nfvpe/telemetry-consumers/vendor/qpid.apache.org/proton.(*Engine).dispatch.func1
0.03s 1.52% |
github.com/redhat-nfvpe/telemetry-consumers/vendor/qpid.apache.org/proton.makeEvent.func1
1.81s 20.76% 20.76% 1.97s 22.59% | runtime.cgocall
0.10s 5.08% | runtime.exitsyscall
0.06s 3.05% | runtime.reentersyscall
> 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: [email protected]
For additional commands, e-mail: [email protected]
