Hi Trustin,
I feel like I was bringing you in a wrong direction.
I start writing a long mail and I was thinking to delete
it, but I feel like perhaps something interesting can get
out from other people (including you, of course).
So let me send this "very" long mail... ;-(
Thank you again for your patience !
Frederic
>Oh I see. IoSession clears all of its statistic properties (i.e.
>resets to 0) as soon as the session is closed. I think this behavior
>is sane for throughput, scheduledWrites, and idleCounts because
>there's no idle and closed connection nor a closed connection with
>non-zero throughput. But I think we need to retain other counters
>like read/written bytes/messages. WDYT?
Well, read/written bytes/messages are interesting of course.
What I was looking is numbers from acceptor and not from
sessions (since they are almost all closed ;-), like a big picture
and easy statistic for the underlying server.
I didn't recheck the code right now, but let me split numbers
in different categories :
- real numbers: like number of bytes/messages read or written
or number of cumulative connections.
The problem with retaining them could be that, on long term
server, those numbers will go in overflow, so probably raising
bad exception, very difficult to catch (specially on bytes numbers).
Of course, for me, the interest is on all sessions, not one specifically.
Those numbers are interesting but one could want to reset to 0
manually those numbers to prevent those exception (and probably
inserting a test somehow to prevent such overflow).
So I think that if we will retaining them, it will brings complexity
and special logic to prevent such exception.
So I feel like it should not be a so good idea to retaine those numbers
in this condition, and letting the user to do it himself by developping
something specific in sessionClosed() method.
The "getWrittenMessages()" seems to be ok, and getting
more than 2^64 messages send by a long term server could
be quite difficult ;-)
"getReadMessages()" seems to be always 0. I will double check later on.
- immediate numbers: like number of current session or scheduled
messages.
Those numbers could be interesting and are correct right now
(at least for current number of sessions).
I think there is no big problem with them.
- compute numbers: like throughput on bytes or message.
I agree that those numbers are very relative to one session.
As they are accessible from Acceptor, I was thinking of
them like the sum of current sessions's throuhputs.
However, it could brings to complicated way to compute it.
One can make a loop over existing and active sessions
to get the current numbers and sum them (how long could it takes ?).
Or one can make on every elapsed time the same on active sessions
to get approximative numbers.
In both cases, already closed session will just be ignored.
Or we can make something like a "largestReadBytesThroughput"
as largestManagedSessionCount, except that what could be its value ?
The max from one session or the max of the sum of all active sessions ?
Should we compute it at each send, receive or close operation ?
Quite expensive I think...
For my test, I think I will go with using sessionClosed() and getting
some of the numbers from session and try to make approximative
throughput computation by using a timer.
However, as it could brings more CPU burning than relevant
information, it will not be my prioritary task right now... ;-(
I feel like I open the Pandora's box ;-)
Yet I should remember that getting such precise values could tend
to big difficulties...
I strongly suggest to not include too much computation
not useful for what Mina has to do, that is the network layer.
The worst thing would be to consume CPU only for statistics
and almost nothing for networking, right ?
Sorry to bring you in what I feel like a "wrong" direction...
Frederic
