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