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 (JIRA)" <ji...@apache.org> on 2007/01/30 10:56:33 UTC

[jira] Resolved: (DIRMINA-332) Improve performance of StatCollector

     [ https://issues.apache.org/jira/browse/DIRMINA-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee resolved DIRMINA-332.
---------------------------------

    Resolution: Fixed
      Assignee: Trustin Lee

Done.  Please close this issue if my fix based on your patch works, Gaston.

> Improve performance of StatCollector
> ------------------------------------
>
>                 Key: DIRMINA-332
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-332
>             Project: MINA
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Gaston Dombiak
>         Assigned To: Trustin Lee
>             Fix For: 1.0.2
>
>         Attachments: changes.patch
>
>
> StatCollector#addSession and StatCollector#removeSession are blocking the entire object. Therefore under heavy load of new sessions or remove of sessions we will have a bottleneck. Instead we can take advantage of "new" Java 5 concurrent util classes.
> Throughput is incorrectly being estimated. It is missing packets/bytes and when dealing with a very big number of sessions the rate will be off. Instead of keeping stats of throughput  we can just stats of total traffic.So stats will change from --> to
> MsgWrittenThroughput --> totalMsgWritten
> MsgReadThroughput --> totalMsgRead
> BytesWrittenThroughput --> totalBytesWritten
> BytesReadThroughput --> totalBytesRead
> The rate can then be estimated by the client of this class. We can add 2 new stats that are very helpful (at least to me):
> 1) scheduled writes: Number of current scheduled writes for all existing sessions.
> 2) queueved events: Number of current queued events for all existing sessions.
> Stat #1 can always be estimated. However stat #2 can only be estimated when the ExecutorFilter is present in the filter chain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.