perfsonar development work

[Chris Welti <>]

Hi Vedrin,

you should re-run tests as we have changed disk read ahead caches 
when changing from python to java. This might also have had an impact on
performance. I also updated our configuration, as we've had lots of link
changes and upgrades this year.
Anyway, I've started the old python installation again in parallel to the
new java session, in case you want to run new comparisons.

python:    http://archive.sonar.net.switch.ch:8090
java:      
http://archive.sonar.net.switch.ch:8180/axis/services/MeasurementArchiveService

Regards,
Chris


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
> 
> 
> 
>