Mailing-List: contact users-help@ace.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@ace.apache.org
Received-SPF: pass (nike.apache.org: domain of marcel.offermans@luminis.eu
 designates 157.55.234.141 as permitted sender)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Poor performance of the REST Client API with hundreds of targets.
From: Marcel Offermans <marcel.offermans@luminis.eu>
In-Reply-To: 
 <OF4C9BC931.570E361B-ONC1257D6A.0056A5B1-C1257D6A.00598FCC@gebit.de>
Date: Tue, 7 Oct 2014 18:46:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-ID: <713BF914-3CA4-4B36-9D13-00CFC7B37BB4@luminis.eu>
References: 
 <OF4C9BC931.570E361B-ONC1257D6A.0056A5B1-C1257D6A.00598FCC@gebit.de>
To: ACE-users Apache ACE users <users@ace.apache.org>

Hello Klaus,

On 07 Oct 2014, at 18:18 pm, Klaus.Meyer@Gebit.de wrote:

> I want to use ACE (version 2.0.1) for deploying POS (Point of sale) =
java=20
> clients. In my scenario I have hundreds or thousands of targets=20
> (POS-clients). I developed an API around the REST-API for creation of=20=

> distributions which point to an associated feature which contains =
about=20
> 100 bundles. On the other side I have developed an API (based on the=20=

> REST-API) which creates targets and connects them to the =
distributions. I=20
> found out that when I import about 1000 targets then the allinone =
server=20
> becomes extremely slow, when managing each kind of data (creating and=20=

> deleting distributions, targets). Allocating a working area needs =
about=20
> one minute or so. Also sometimes I get exceptions from the Felix=20
> preference service. Do you have already experiences whith a lot of=20
> targets, are there any issues known about performance ? Can you give =
me=20
> 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 users.
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