perfsonar development work

[Maciej Glowiak <>]

Szymon Trocha wrote:
> Slawomir Trzaszczka pisze:
> > Hi all,
> >
> > I've created performance tests for LS1 and LS2. In these tests, I used
> > larger "size" of services then in  previous version of tests - services
> > contain more interfaces(100,500,1000).
>
> Hi Slawomir,
>
> Thank you for testing. Looks interesting. Deregistration improvement is 
> impressive but what worry us most is I would say querying and here the 
> difference is not much visible.
>
> What was the exact query you sent to LS? This may also has impact.
>
> What do you think of putting the documents to GN3 wiki (they are already 
> published to the list so no problem with public access)? Maybe in 
> Service Implementation or Testing sections.
>
> regards,

Hi,

Szymon you should look at the performance problem globally. We've 
already increased the performance by 20% using new data structures for 
processing data in psBase2 (using Axis2, getting rid of unnecessary 
convertions, using class Element instead of old NMWG classes) - Slawek 
sent those results on the mailing list in October (16th Oct 2009).

Next performance increase was done by using something we called 
"Multiple Files" where each Lookup Information from single service is in 
separate structure in the XML database (like separate XML files). It was 
promising even in LS1 (I was presenting similar results in Montpellier 
meeting - 3 years ago! ;) Recently, Slawek resolved some synchronization 
issues and made it working without any problems.

Regarding XQuery - it was already the fastest part of the LS, so I don't 
think we could speed it up much more. It's rather the eXist DB 
performance issue than the LS. But, come on, 55 to 85 milliseconds per 
query is not so huge time, is it? Query is the fastest operation, so 
don't expect much more.

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.

Interesting idea, as we are slowly moving towards queries without using 
XQuery, so getting rid of XML DB might not be so big problem as before.

Antoine, now we're using XML DB because we store XML data in XML 
collections. There are some extensions for PostgreSQL and MySQL for 
stoing XML structures, but they work with XPath, not the XQuery. I think 
that would be "political" decision in which direction we should go. If 
we get rid of XML DB we will also get rid of XQuery, but will make the 
service more efficient. If we still want use XQuery, we can try to 
optimize the LS code or DB connection or can use Michael's idea. We must 
also remember that Java LS is not the only one and our hLS must 
cooperate with perl LS.

Best regards
Maciej



--

 --------------------------------------------------------------------
| Maciej Glowiak        Network Research and Development            ||
| 

     Poznan Supercomputing and Networking Center ||
| (+48 61) 858 2024        -- skype_id: maciej_psnc  -- GG: 4526858 ||
|                          -- jabber:   

    ||
 ====================================================================