You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2007/01/24 12:59:54 UTC
Throughput monitoring issues.
Hi folks,
1) We need 'built-in per-service performance counter in IoService'.
In the recent talk with Julien about throughput monitoring, we realized that
we need to reapproach to the throughput monitoring issue from a different
point of view.
Until now, we focused on providing per-session throughput. IoSession
provided appropriate performance counters to calculate per-session
throughput, but IoService didn't. But what would an administrator want to
see from his management console? Julien and I think it's not throughput for
an individual session but throughput for the service he or she is managing.
For now, I/O threads doesn't provide any performance counter from the
service standpoint, so we have a lot of difficulties in calculating
meaningful performance factors without slowing down a network application.
Of course, we still need to monitor an individual session's performance
counters, but not usually for most cases, especially for stateless protocols
like HTTP.
2) Gaston's patch
Gaston's patch (https://issues.apache.org/jira/browse/DIRMINA-332) contains
several interesting ideas. We could probably borrow his idea that uses a
queue to reduce synchronization in 1.0.x. Other stuff would be incorporate
with the 'built-in per-service performance counter in IoService' because
there's no backward compatibility in the patch.
I must admit that we have design flaw in per-service performance counter
calculation, and it is hard to fix it without breaking backward
compatibility or API addition. Resolving this issue in trunk (
2.0-M1-SNAPSHOT) would be the better option, although it breaks my heart.
:(
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Throughput monitoring issues.
Posted by Trustin Lee <tr...@gmail.com>.
On 1/24/07, Julien Vermillard <jv...@archean.fr> wrote:
>
> Le mercredi 24 janvier 2007 à 20:59 +0900, Trustin Lee a écrit :
> > Hi folks,
> >
> > 1) We need 'built-in per-service performance counter in IoService'.
> >
> > In the recent talk with Julien about throughput monitoring, we realized
> that
> > we need to reapproach to the throughput monitoring issue from a
> different
> > point of view.
> >
> > Until now, we focused on providing per-session throughput. IoSession
> > provided appropriate performance counters to calculate per-session
> > throughput, but IoService didn't. But what would an administrator want
> to
> > see from his management console? Julien and I think it's not throughput
> for
> > an individual session but throughput for the service he or she is
> managing.
>
> Actualy you can see the two, the per service stats are in the
> StatColector, and IoSession stats attached to them. Basicly per service
> stats are sum of active session stats, plus addition of the closed
> sessions in the last polling period.
True. What I wanted to say is that we need to *focus* on per-service
statistics rather than per-session statistics. Per-service statistics can
be calculated more easily and it's not for now. We need to fix it in 2.0.
> For now, I/O threads doesn't provide any performance counter from the
> > service standpoint, so we have a lot of difficulties in calculating
> > meaningful performance factors without slowing down a network
> application.
> > Of course, we still need to monitor an individual session's performance
> > counters, but not usually for most cases, especially for stateless
> protocols
> > like HTTP.
>
> Computing the per service, from collected read/write totals in IoService
> that will be much faster and won't need to compute all the per session
> stats. I think the per session throughput stats needs to be enabled
> manualy by the user, if needed.
I can't agree more, either.
> 2) Gaston's patch
> >
> > Gaston's patch (https://issues.apache.org/jira/browse/DIRMINA-332)
> contains
> > several interesting ideas. We could probably borrow his idea that uses
> a
> > queue to reduce synchronization in 1.0.x. Other stuff would be
> incorporate
> > with the 'built-in per-service performance counter in IoService' because
> > there's no backward compatibility in the patch.
> >
> > I must admit that we have design flaw in per-service performance counter
> > calculation, and it is hard to fix it without breaking backward
> > compatibility or API addition. Resolving this issue in trunk (
> > 2.0-M1-SNAPSHOT) would be the better option, although it breaks my
> heart.
> > :(
>
> For 1.X we need to fix synchro issues. for 2.X we need to change the API
> for being able to compute per service stats without needing to poll all
> the IoSessions. It'll improve performance a for people who just want to
> see the service throughtput.
Good. What do you think about it, Gaston?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Throughput monitoring issues.
Posted by Julien Vermillard <jv...@archean.fr>.
Le mercredi 24 janvier 2007 à 20:59 +0900, Trustin Lee a écrit :
> Hi folks,
>
> 1) We need 'built-in per-service performance counter in IoService'.
>
> In the recent talk with Julien about throughput monitoring, we realized that
> we need to reapproach to the throughput monitoring issue from a different
> point of view.
>
> Until now, we focused on providing per-session throughput. IoSession
> provided appropriate performance counters to calculate per-session
> throughput, but IoService didn't. But what would an administrator want to
> see from his management console? Julien and I think it's not throughput for
> an individual session but throughput for the service he or she is managing.
Actualy you can see the two, the per service stats are in the
StatColector, and IoSession stats attached to them. Basicly per service
stats are sum of active session stats, plus addition of the closed
sessions in the last polling period.
>
> For now, I/O threads doesn't provide any performance counter from the
> service standpoint, so we have a lot of difficulties in calculating
> meaningful performance factors without slowing down a network application.
> Of course, we still need to monitor an individual session's performance
> counters, but not usually for most cases, especially for stateless protocols
> like HTTP.
Computing the per service, from collected read/write totals in IoService
that will be much faster and won't need to compute all the per session
stats. I think the per session throughput stats needs to be enabled
manualy by the user, if needed.
>
> 2) Gaston's patch
>
> Gaston's patch (https://issues.apache.org/jira/browse/DIRMINA-332) contains
> several interesting ideas. We could probably borrow his idea that uses a
> queue to reduce synchronization in 1.0.x. Other stuff would be incorporate
> with the 'built-in per-service performance counter in IoService' because
> there's no backward compatibility in the patch.
>
> I must admit that we have design flaw in per-service performance counter
> calculation, and it is hard to fix it without breaking backward
> compatibility or API addition. Resolving this issue in trunk (
> 2.0-M1-SNAPSHOT) would be the better option, although it breaks my heart.
> :(
>
> Trustin
For 1.X we need to fix synchro issues. for 2.X we need to change the API
for being able to compute per service stats without needing to poll all
the IoSessions. It'll improve performance a for people who just want to
see the service throughtput.
Julien