perfsonar development work

[Joe Metzger <>]

Vedrin,
Another factor which might be skewing the results is that
my box is not idle.  Somebody is sending bursts of ill-formed
queries to my system generating around 15 thousand "FATAL"
errors entries in my log files a day.

Anybody know who sonar1.munich.cn is?  They were the source
of the latest burst.

This also brings up the issue that the current MA does not
do the logging that I would like to see on all production
services.  IE, who is sending requests to the server, what
are the requests, and were they successful?  A single
log message per message containing source IP, message type,
message size, and some indication about the number of
meta-data blocks, keys and/or data elements sent back
would be a good start.


--Joe



Vedrin Jeliazkov wrote:
> Hi,
>
> As Joe has suggested, I've run again the perfsonarUI 'Retrieve all' tests
> against ESnet's (and also SWITCH's) newly installed RRD MAs (perfSONAR-1.0).
> In the table below you can find the timings I've got, compared to the
> respective older service releases.
>
> 1. One MetadataKeyRequest (summary) [sec]       
> 2. Number of Interfaces (NoI)   
> 3. (NoI x 2) SetupDataRequests (detailed summary) [sec]
> 4. Average SetupDataRequest [msec]
> 5. Average Link latency (RTT) [msec]
> 6. Implementation
>         
>                 (1)     (2)     (3)     (4)     (5)     (6)     
>         
> ESNET           180     415     468      564    202     Java 0.1 (EGEE tag)
> ESNET            63     419     890     1062    206     perfSONAR-1.0
> SWITCH		  5	272	488	 897	 51	Python 0.1-19 
> SWITCH		 17	272	171	 314	 54	perfSONAR-1.0
>
> There's no any common trend between the two cases, probably because the older
> service releases were different:
>
> - MetadaKeyRequest response time is 3 times better for ESnet, but more than 3
> times longer for SWITCH;
>
> - SetupDataProcessing is 2 times longer for ESnet, but almost 3 times better
> for SWITCH;
>
> Having in mind the recent tests with Java RRD MA from SVN carried out here at
> ISTF, I guess that MetadataKeyRequest processing performance would not be
> anymore a big issue - we could expect an additional 3.5 times improvement, as
> observed in ISTF's case.
>
> There could be some concerns about SetupDataRequest processing performance. I
> wonder why ESnet's newly installed service is taking 2 times more time than
> the old one in this case... There are so many contributing factors that it
> wouldn't be easy to answer this question. However, from end user's perspective
> I think we should make all reasonable efforts to improve the performance in
> each new release, in addition to the added new features.
>
> Kind regards,
> Vedrin