[
https://issues.apache.org/jira/browse/TS-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358962#comment-14358962
]
ASF GitHub Bot commented on TS-3436:
------------------------------------
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/178#issuecomment-78525819
- please rebase so that it's clear which patches are yours
- please update the milestones support in the xdebug plugin
- please include the apidefs.h.in changes
From an API point of view, I'm not convinced that this should be published
through the milestones. Milestones are basically an ordered set of relative
timestamps based on the state machine. I don't really see how API callout times
makes sense for that.
> Add milestone data for API times
> --------------------------------
>
> Key: TS-3436
> URL: https://issues.apache.org/jira/browse/TS-3436
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Alan M. Carroll
> Assignee: Alan M. Carroll
>
> Add two new milestones that track API time, "active" and "total". These are
> reasonably equivalent to "wall clock time" and "cpu time" concepts for
> process. The total time measures how long, in real time, a transaction spends
> involved with API callouts in plugins. The active time tracks the amount of
> time spent in an API callout. When these two values are different this means
> time is being spent either in lock contention to run the plugin continuation
> or waiting for the plugin to re-enable the transaction. Originally I had just
> the "total" counter but I think the ability to detect contention and wait is
> very valuable.
> The values are a bit odd - they are the actual amount of time spent plus the
> start time of the state machine. I debated for a while about that with some
> other contributors and the concenssus was that overall the best option
> because it makes those milestones behave exactly like all the others (e.g.,
> you subtract sm_start to get the real value).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
