[
https://issues.apache.org/jira/browse/SAMZA-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Riccomini updated SAMZA-421:
----------------------------------
Attachment: update-timer-speed.png
Ah, didn't notice that you attached a screenshot. What that's showing is that
10% of time is spent in process, and 90% in whatever's being wrapped by
updateTimer. Based on this stack trace, the 90% is being spent on choosing the
next message to process. Usually when this much time is being spent in
SystemConsumers.choose, it's because there's blocking while the chooser waits
for more messages.
I'm attaching a screenshot that shows that the update() method only takes .6%
of CPU time. The rest is being spent in SystemConsumers.choose,
TaskInstance.process, or RunLoop self time.
Oddly, RunLoop's self time is taking > 25% of CPU cycles, which sounds broken,
but that'll have to wait for a different ticket.
In any case, I thnk .6% CPU is acceptable.
> Test the performance before and after adding the Timer metric
> -------------------------------------------------------------
>
> Key: SAMZA-421
> URL: https://issues.apache.org/jira/browse/SAMZA-421
> Project: Samza
> Issue Type: Test
> Components: metrics
> Reporter: Yan Fang
> Assignee: Yan Fang
> Labels: newbie
> Attachments: testTimer1.png, update-timer-speed.png
>
>
> As
> [recommended|https://issues.apache.org/jira/browse/SAMZA-349?focusedCommentId=14128365&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14128365]
> by Martin in SAMZA-349, it's worth testing the performance before and after
> implementing the Timer metric.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
