Hi Andy,
Thanks for the quick reply.
I modified a little the configuration so that the flush is done after
30s and the window is 15s to show better the points 1) and 2).
I did 4 consecutive xrdcp's. Nothing else was accessing the xrootd
dataserver, so there were no interference and no parallel activity.
I also attached the logs and binary dumps I obtained from my ML module.
Andy Hanushevsky wrote:
> The flush rule is approximate. From the attached file I could
> potentially read that it was working as well as it wasn't. That's why I
> need the binary dump.
The reason I need the flush rule is that I would like to do a somewhat
real-time analysis and reporting of the system's status. I cannot do
this if I get the information about a session only when the buffer fills
or when the user disconnects (I would have to keep the history for an
undefinite time, update all of it whenever I receive a datagram and have
a final result only when the system stops). If I would get this
information at least after this flush period, that would be the history
that I would have to keep and update. This way I could report all the
values with a delay of flush period.
>
>> 2) "end of last window" == "start of this window" for each two
>> consecutive window entries from the i/o trace. You can grep the attached
>> file for WINDOW to see this. Is this correct?
>
> True, if both traces occured in parallel. Since xrootd is a parallel
> server, multiple I/O events can occur in the same window but be reported
> in separate packets. It's up to the collector to merge the information.
From what I understand from the documentation, the events are grouped
in windows, and a window is defined by two consecutive window entries.
From what I get, it seems that the thisStartTime from the first window
entry == lastEndTime from the second window entry, so the window size
would be zero. Is this correct, considering that I have only one client
running?
.. trace events ..
Reading Trace Message
WINDOW: lastEND: Thu Apr 28 00:05:54 CEST 2005 thisSTART: Thu Apr 28
00:06:09 CEST 2005
.. more events ..
WINDOW: lastEND: Thu Apr 28 00:06:09 CEST 2005 thisSTART: Thu Apr 28
00:06:24 CEST 2005
.. other events ..
>> 4) I think that the number of bytes actually sent after a READ request
>> could be more useful than the number of the requested bytes, in order to
>> have a better precision when computing the total number of bytes sent to
>> the clients by a xrootd dataserver.
>
> While this is true, it would seriously impact the server's performance.
> In designing the monitoring, we made the concious choce to make
> trade-offs to the benefit of the server's performance; even if that
> meant reduced accuracy. This is how we can support such extensive
> monitoring with only a small degradation in server performance (which in
> a real sense provides more realistic information when monitoring is
> enabled).
However, I see that you keep and sum the exact number of bytes read or
written by the client, so you do some operations... Anyway I could live
with this :-) the first two points are more important.
Cheers,
Catalin.
|