ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: Poor performance of the REST Client API with hundreds of targets.
Date Tue, 07 Oct 2014 16:46:19 GMT
Hello Klaus,

On 07 Oct 2014, at 18:18 pm, wrote:

> I want to use ACE (version 2.0.1) for deploying POS (Point of sale) java 
> clients. In my scenario I have hundreds or thousands of targets 
> (POS-clients). I developed an API around the REST-API for creation of 
> distributions which point to an associated feature which contains about 
> 100 bundles. On the other side I have developed an API (based on the 
> REST-API) which creates targets and connects them to the distributions. I 
> found out that when I import about 1000 targets then the allinone server 
> becomes extremely slow, when managing each kind of data (creating and 
> deleting distributions, targets). Allocating a working area needs about 
> one minute or so. Also sometimes I get exceptions from the Felix 
> preference service. Do you have already experiences whith a lot of 
> targets, are there any issues known about performance ? Can you give me 
> some ideas what I can do next to solve my problem.

Let me start by explaining a bit about how the ACE client code works, as that will give you
more insight into this problem.

ACE consists of a server, a client and an OBR repository. Each can be deployed independently,
but for convenience we also have an "all-in-one" version. The client is what you need to manipulate
the repository, and fundamentally the client works by "checking out" a copy of the current
configuration, manipulating it locally and, when done, "committing" the new configuration
back to the server.

Now, the client has an OSGi API (services) you can talk to, and on top of that we built three
different APIs:

1. The web UI based on Vaadin.
2. The REST API.
3. The Gogo Shell API.

The first two can work "over the network" with a browser or REST client being the primary
The last one works "on the client" and is therefore usually a lot faster. We use it for all
kinds of scripted access such as in continuous integration scenarios.

That being said, I have a few recommendations:

First of all, if you build your own API, I would consider building it directly on top of the
OSGi, service based API just like the 3 existing clients do. That will be a lot quicker than
interfacing, over the network, with a remote client.

Second of all, you might want to consider the Gogo Shell API to script these things. We use
this in continuous integration and if it helps I can provide some examples (but I probably
need to know a bit more details about the deployment process you are using).

Finally, we have tested ACE with 100's to 1000's of targets. I would say that is possible.
I currently would not go to 10.000's of targets, our benchmarks have shown that you are running
into some limits there. However, we have options to partition the targets into smaller groups
within ACE, so if necessary I can go into that a bit more and explore if that is an option
that could help you. Also, one thing that slows ACE down is when you have "auto configuration"
XML files which are templates that have parameters that need to be substituted for each target.
We are still discussing ways to optimize that.

I hope this gives you some pointers/suggestions that help. Feel free to follow up if you have
more questions.

Greetings, Marcel

View raw message