[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Service Lookup by GUID very Slow - the Framework Scalability

The key question is about the scalability of the runtime, in terms of

 

-         Number of services, 100K, 1M, 10M, etc

-         Registering and unregistering them, churn over long period of time

-         Is it primarily memory bound? Assuming that services are not CPU heavy or thread hungry

 

Some details of the experiment we had:

 

The code is pretty straightforward. We only have a 5 Service Classes. We add an ID property to each service object we register and later look it up using that ID. The look up through getServiceReferences() took 4-5 seconds when we have 200K services registered.

 

Also, can someone shed some light for the following questions:

 

-        Do you think lazy service creation may be the reason? Is lazy creation the default? How to configure it?
-        Can you outline the steps to use
ServiceTrackerCustomizer to build index? Do you mean trapping the registration events and build the needed indexes?

 

Service Registration: we register all the 200K service instances in a loop. They are one of 5 different server classes.

 

BundleContext bc,

 

            Dictionary<String, String> props = new Hashtable<String, String>(1);

            props.put(âIDâ, âID0000001â);

            bc.registerService(ServiceClass, serviceObject, createProperties(props));

 

 

Service Look up:

 

            BundleContext bc,

            bc.getServiceReferences(ServiceClass, "(ID=ID0000001)â);

 

 

Thank you,

Stanley

 

From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of BJ Hargrave
Sent: Friday, May 04, 2012 10:19 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Service Lookup by GUID very Slow

 

Equinox also indexes by objectClass alone. So I am not sure what the discrepancy is here. Would be nice to have the test case code to analyze. Stanley, can you post a gist with the code?

--

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the
OSGi Alliance
hargrave@xxxxxxxxxx


office: +1 386 848 1781
mobile: +1 386 848 3788







From:        "Richard S. Hall" <heavy@xxxxxxxxxxxxxx>
To:        Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
Date:        2012/05/04 13:16
Subject:        Re: [equinox-dev] Service Lookup by GUID very Slow
Sent by:        equinox-dev-bounces@xxxxxxxxxxx





Just a side comment...

On the Felix framework, it is technically possible to index services on arbitrary service properties, but we don't provide any configuration properties to do so. By default, we only index on objectClass, which I assume Equinox does as well.

If all of your services have the same objectClass, then it will regress to a linear search. There is no other magic to make it faster in Felix. I would expect something similar in Equinox. If that is not the case, then yeah it sounds like there is an issue.

-> richard

On 5/4/12 12:41 , Stanley_Poon@xxxxxxxx wrote:
Tom,
 
You are right on. I am using a simple filter. We just added a GUID property to each service. Two follow up questions:
 
-        We ran the same tests on Felix and Knopflerfish and get 100ms response time. This is about 50X. I am wondering there may be something wrong in the environment. Do you think JVM settings like Perm generation size helps? I have Xmx=2GB, Xms=1GB and XXMaxPermSize=64MB.
-        Do you think lazy service creation may be the reason? Is lazy creation the default? How to configure it?
-        Can you outline the steps to use ServiceTrackerCustomizer to build index? Do you mean trapping the registration events and build the needed indexes?
 
Thank you,
Stanley
From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Watson
Sent:
Friday, May 04, 2012 5:40 AM
To:
Equinox development mailing list
Subject:
Re: [equinox-dev] Service Lookup by GUID very Slow

 

I was also not sure what you meant by GUID.  After some thought I think you probably mean the service id or perhaps the service pid (service.id and service.pid properties)?

And by lookup I assume you are using some kind of service filter, for example "(service.id=23)" with a call to BundleContext.getServiceReferences.  I will say that the service registry is not optimized for this kind of lookup.  You are far better keeping your own data structure that optimizes the lookup over the set of service references and indexes on the keys that you want to use to lookup service references.  This can easily be done with a ServiceTrackerCustomizer.


Tom



Inactive hide details for BJ Hargrave---05/03/2012
            10:04:05 PM---What is service lookup by GUID? Services don't
            have globally uBJ Hargrave---05/03/2012 10:04:05 PM---What is service lookup by GUID? Services don't have globally unique identifiers. Can you provide more information on the specif


From:


BJ Hargrave/Austin/IBM@IBMUS


To:


Equinox development mailing list <
equinox-dev@xxxxxxxxxxx>,


Date:


05/03/2012 10:04 PM


Subject:


Re: [equinox-dev] Service Lookup by GUID very Slow

 






What is service lookup by GUID? Services don't have globally unique identifiers. Can you provide more information on the specifics of your lookup? Such as the code snippet?


--

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the
OSGi Alliance
hargrave@xxxxxxxxxx


office: +1 386 848 1781
mobile: +1 386 848 3788







From:        
<Stanley_Poon@xxxxxxxx>
To:        
<equinox-dev@xxxxxxxxxxx>,
Date:        
2012/05/03 16:54

Subject:        
[equinox-dev] Service Lookup by GUID very Slow
Sent by:        
equinox-dev-bounces@xxxxxxxxxxx






In an experiment to have 200K of services registered, the service lookup by GUID is exceedingly slow â more the 4 seconds per lookup.


There are enough RAM (8G) and heap (2G) allocated.


What would be the reason of the slowness of the lookup? Any settings to start the framework to improve this?



Thanks,

Stanley
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev



_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

GIF image

PNG image

PNG image