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: [email protected] [mailto:[email protected]]
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<http://www.osgi.org/>
[email protected]<mailto:[email protected]>
office: +1 386 848 1781
mobile: +1 386 848 3788
From: "Richard S. Hall"
<[email protected]<mailto:[email protected]>>
To: Equinox development mailing list
<[email protected]<mailto:[email protected]>>,
Date: 2012/05/04 13:16
Subject: Re: [equinox-dev] Service Lookup by GUID very Slow
Sent by:
[email protected]<mailto:[email protected]>
________________________________
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 , [email protected]<mailto:[email protected]> 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: [email protected]<mailto:[email protected]>
[mailto:[email protected]] 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
[cid:[email protected]]BJ 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
<[email protected]<mailto:[email protected]>>,
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<http://www.osgi.org/>
[email protected]<mailto:[email protected]>
office: +1 386 848 1781
mobile: +1 386 848 3788
From: <[email protected]<mailto:[email protected]>>
To: <[email protected]<mailto:[email protected]>>,
Date: 2012/05/03 16:54
Subject: [equinox-dev] Service Lookup by GUID very Slow
Sent by:
[email protected]<mailto:[email protected]>
________________________________
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
[email protected]<mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[email protected]<mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[email protected]<mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[email protected]<mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: image001.gif>>
<<inline: image002.png>>
<<inline: image003.png>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
