ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram Pouwelse <b...@pouwelse.com>
Subject Re: How to keep ace performance consistent
Date Thu, 09 Jan 2014 10:55:42 GMT
Hi Marcel,

The issue with the deploymentversionlimit is when I re-configure the
deployment version limit after using Ace for a while. I noticed that the
repository file was growing over time [1] and wanted to know if that was
causing the performance degradation and if there is a way to keep it from
growing that fast ;).

If it's (currently) not possible to configure the deploymentversionlimit
after you start using Ace I'll start over with a clean server and see how
that works out.

I've watched the presentation Jago and jou did after you mentioned it in an
earlier thread on this list and I'm already experimenting with it to see
how this works out for us.

Thanks!
Bram

[1]
1    61
10   67K
20   146K
30   225K
40  296K
...
100  749K
150  1.2M


2014/1/9 Marcel Offermans <marcel.offermans@luminis.eu>

> Hello Bram, Paul,
>
> What Paul said is not entirely accurate. Web sessions are being cleaned
> up. However, with the REST interface, sessions do currently stay around
> because of ACE-442 [1]. What you can do to make the memory grow a lot less
> quickly is to make sure that the workspace that you create in the REST
> session is being deleted again (after you've committed it back to the
> server). 99% of all resources are in that workspace so deleting it will
> free almost all the memory. Not a permanent solution, but the best you can
> do until that issue is resolved.
>
> There are two other things you can consider to improve this situation:
>
> 1) The "client" part of ACE is the one that uses the most memory.
> Therefore, instead of deploying the "all-in-one" server, you can also
> deploy the "server", "obr" and "client" separately. The client is only
> necessary when changing something in the ACE configuration. The targets
> talk to the "server" (and the "server" to the "obr" to fetch the
> artifacts). By deploying them separately, you can more easily simply
> restart the client, or just start it "on demand" (see 2)).
>
> 2) Instead of using the REST API, you can also use the client (run it on
> your CI server as part of the build) and talk to this client using a script
> for the GoGo shell. This is something we added after we did the REST API,
> so its fairly new, but we do already use it in our CI scenario. If you want
> to learn a bit more about this approach, Jago and I did a talk on it at
> EclipseCon EU last year [2].
>
> About the deploymentversionlimit, that should have worked. You should
> configure it before you start using ACE, but this sounds like a bug. Is it
> as easy as configuring this limit and then you instantly get this error? If
> so, please file a bugreport and I'll look into it. That limit was created
> to make sure the server itself and the diskspace it consumes scales
> linearly with the number of targets (instead of exponentially with targets
> * versions as it does without the limit) so I do advise you to keep it set.
> Especially if you don't have targets with "really old versions" (which
> happens if targets are off-line for long periods of time) and even in such
> cases, all you loose is the ability for the server to send a delta between
> this really old version and the current one: instead in that case it will
> just send everything again. The agent is smart enough to deal with that,
> you're just wasting some bandwidth, sending bundles you probably don't
> need. That's the trade-off.
>
> Hope this helps.
>
> Greetings, Marcel
>
> [1] https://issues.apache.org/jira/browse/ACE-442
> [2] http://www.youtube.com/watch?v=4S_zvgG_MLw
>
> On 08 Jan 2014, at 22:19 pm, Bram Pouwelse <bram@pouwelse.com> wrote:
>
> > Hi Paul,
> >
> > The deployment is automated using the rest interface. Sessions not being
> > closed would be my first guess but restarting Ace would close such
> > sessions? The performance is not much better after restarting the ace
> > server.
> >
> > The version I'm currently using is trunk from 16-11-2013
> >
> > Bram
> >
> >
> > 2014/1/8 Paul Bakker <paul.bakker@luminis.eu>
> >
> >> Hi Bram,
> >>
> >> Are you using the web user interface? The problem that you are
> experiencing
> >> is most probably related to sessions not being cleared. We are running
> >> completely without the UI (we scripted deployments) and that works
> without
> >> any problems after many deployments.
> >> Besides that, on which version of ACE are you running?
> >>
> >> Cheers,
> >>
> >> Paul
> >>
> >>
> >> On Wed, Jan 8, 2014 at 8:37 PM, Bram Pouwelse <bram@pouwelse.com>
> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I have a question regarding performance of Ace, and most important part
> >> is
> >>> how to keep the performance consistent over time. Now we've automated
> >>> moving artifacts to Ace and converting bndrun configurations from
> >> bndtools
> >>> to features and distributions Ace has made it to production at our
> >> company.
> >>>
> >>> There is one little issue, the deployments from the Jenkins server to
> Ace
> >>> are becoming slower when we just started deployment took seconds now
> it's
> >>> over 10 minutes. Also ace seems to need more and more memory.
> >>>
> >>>
> >>> I've tried to change the deploymentversionlimit
> >>> in conf/org.apache.ace.client.repository.cfg to 5 instead of the
> default
> >>> value of -1 (unlimited) but after that change I get an exception that
> the
> >>> repository is busy [1] (even after 30 minutes of waiting).
> >>>
> >>>
> >>> Is limiting the deployment versions the way to get the performance back
> >> to
> >>> the level of when we just started using ace? and if so how can I
> resolve
> >>> the "repository is busy" problem
> >>>
> >>> Are there other configuration options that can improve performance?
> >>>
> >>>
> >>> Thanks!
> >>>
> >>> Bram
> >>>
> >>>
> >>> [1]
> >>> g! ws = (ace:cw)
> >>> $ws commit
> >>> gogo: ConversionException: java.lang.IllegalStateException: The
> >> repository
> >>> is currently busy, so no objects can be removed.
> >>> ---- Debugging information ----
> >>> message             : java.lang.IllegalStateException: The repository
> is
> >>> currently busy, so no objects can be removed.
> >>> cause-exception     : java.lang.IllegalArgumentException
> >>> cause-message       : java.lang.IllegalStateException: The repository
> is
> >>> currently busy, so no objects can be removed.
> >>> class               :
> >>> org.apache.ace.client.repository.impl.RepositorySerializer
> >>> required-type       :
> >>> org.apache.ace.client.repository.impl.RepositorySerializer
> >>> path                :
> /repository/deploymentversions/deploymentversion[8]
> >>> line number         : 19543
> >>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message