perfsonar development work

[Nina Jeliazkova <>]

Antoine Delvaux wrote:

Le 4 déc. 2009 à 13:53, Szymon Trocha a écrit :
  

Jeff W.Boote pisze:
    

Michael's idea is very interesting, as it may be the next step for 
increasing the speed of the service. I was also thinking about it but 
for java implemnetation of gLS, as there the structure of data is 
"static" - all fields are defined and there won't be any unexpected 
data. In hLS there is opposite situation, because LS doesn't know what 
the data registered by "a service" will be.
        

Can someone please post Michael's idea to the full list? I don't believe 
I have seen it.
      

I think it was Maciej who referred to it. I think I didn't see Michael's 
e-mail too.
    

I thought it was on list, but here it is, if it's the one you were referring to.

Antoine.

  

---

Subject:

Re: [pS-dev] performance tests for lookup service

From:

Michael Bischoff

Date:

Thu, 26 Nov 2009 19:15:24 +0000

To:

Antoine Delvaux

To:

Antoine Delvaux

CC:

Slawomir Trzaszczka , , Maciej Glowiak

Hello all,

The LS part of the perfSONAR protocol depends upon xquery and as far  
xml databases go the choices are limited. But considering the xquery  
part isn't used in all requests and those that due make up (rough  
estimate) <20% of the requests it might pay off to keep two data  
structures. One 'slower' that allows one to execute xqueries one that  
is for the bulk of the messages. I'm working on a prototype to see  
what this approach yields / could yield.

With the above in mind is anyone prepared to collect statistics on the  
distribution of message types?
Are the benchmarks avail / would you be prepared to run them again  
against the prototype

  

With this line of thinking, does it make sense to introduce specific constructs in the  LS protocol for querying, in order to be independent of XQuery, and thus have more freedom in implementation?

Best regards,
Nina

kind regards,

Michael

Quoting Antoine Delvaux :

  

Hi Slawek,

Indeed, interesting work and results.  We can say that pSbase2 is   
about 2 times more efficient than pSbase1, so we're already hoping   
for pSbase10 ;-)

I guess you performed those tests in a serial fashion: doing all   
registrations, than all queries, then all deregistrations.  Would   
doing it in a more random fashion (registrations, queries and   
deregistrations not happening all together), more similar to real   
world usage, change the result pattern?

You say the bottleneck is eXistDB, would it be possible to make a   
prototype using some other DB engine like Postgresql to see if there  
 could be any other performance gain.  Or does our code uses  
advanced  XML functions only provided by eXistDB?

Beste regards,
--
Antoine Delvaux                                    Systems Engineer
DANTE                                                 Skype: toninb
http://www.dante.net                            Tel: +221.778197275
PGP fingerprint: DC65 0D8B 6938 9229 33C3  18CA 4EB6 09D3 A333 3378