[ 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org