|Re: [equinox-dev] Service Lookup by GUID very Slow - the Framework Scalability|
Thank you Neil.
But the exact same example runs 50X faster on the other two OSGi runtime. Any thoughts? And we observed the other runtime used more memory. Will they be using some indexing (in memory)?
* No, services are not created lazily by default. You are creating the services yourself in your code sample, i.e., the 'serviceObject' variable.
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?
Service Registration: we register all the 200K service instances in a loop. They are one of 5 different server classes.
Dictionary<String, String> props = new Hashtable<String, String>(1);
bc.registerService(ServiceClass, serviceObject, createProperties(props));
Service Look up:
From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of BJ Hargrave
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?