Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] Java 0.1 (EGEE tag) vs. perfSONAR-1.0 RRD MA performance

Subject: perfsonar development work

List archive

Re: [pS-dev] Java 0.1 (EGEE tag) vs. perfSONAR-1.0 RRD MA performance


Chronological Thread 
  • From: Roman Lapacz <>
  • To: Vedrin Jeliazkov <>
  • Cc: , Nicolas Simar <>, Eric Boyd <>, "Jeff W. Boote" <>
  • Subject: Re: [pS-dev] Java 0.1 (EGEE tag) vs. perfSONAR-1.0 RRD MA performance
  • Date: Thu, 24 Aug 2006 09:41:39 +0200

Vedrin Jeliazkov wrote:
Hi,

Hi,

I've run some simple tests against the upgraded RRD MA at ESnet

Do they use eXist to store the metadata configuration file?

in an attempt
to compare its performance against the older release. Here are the timings
I've got:

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 296 419 1600 1909 206 perfSONAR-1.0

Unfortunately the release 1.0 does not contain recent changes, which I hope, improve the performance. It would be interesting to see the tests of RRD MA from svn trunk or the next release (question to the release team: is there a timetable for this?).


BTW. Vedrin, are you a member of the release team? (I remember the discussion in Cambridge with the decision to ask you to have you there as you are a very active perfSONAR member).


Roman



As you can see, the differences in the number of interfaces and the network
latency are insignificant, while MetadataKeyRequest's and SetupDataREquest's
processing time is much longer in the new service version, when compared to
the older one (multiplied by 1.6 and 3.4 respectively).

If the service is running on the same hardware platform, than we could
conclude that there is a significant performance loss in the new version,
which is most probably due to some newly introduced scalability issue. Perhaps
some more comprehensive tests should be run in order to understand and resolve
this issue.

Kind regards,
Vedrin





Archive powered by MHonArc 2.6.16.

Top of Page