 |
 |
Hi Catlin, Just to make sure we are on the same "page" so to speak. You can get auto-flushing but you must create a monitoring stream that does not include I/O events. Monitoring streams that include I/O events cannot be flushed. So, if you add in files events then you wind up delaying files information as well. If you really need i/o events (generally, these events tell you little about the server and are only useful for tuning an application), send them to an offline data collector. Beleive me, in a real-life system you will not be able to analyze i/o events in real time. Andy > 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. >