perfsonar development work

[Antoine Delvaux <>]

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.

--- Begin Message ---

• From: Michael Bischoff <>
• To: Antoine Delvaux <>
• Cc: Slawomir Trzaszczka <>, "" <>, Maciej Glowiak <>
• Subject: Re: [pS-dev] performance tests for lookup service
• Date: Thu, 26 Nov 2009 19:15:24 +0000
• Accept-language: en-US, en-GB
• Acceptlanguage: en-US, en-GB

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

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



--- End Message ---