Mailing-List: contact users-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@archiva.apache.org
MIME-Version: 1.0
In-Reply-To: <518F907E.2060605@free.fr>
References: <518EC894.7090406@free.fr>
 <CAPoyBqTwij8tph06Bpjrtf+-WW_KkTGCh_2F4DAWXpQ_qe+ONg@mail.gmail.com>
 <518F907E.2060605@free.fr>
From: Olivier Lamy <olamy@apache.org>
Date: Sun, 12 May 2013 23:03:40 +1000
Message-ID: 
 <CAPoyBqT-K=ODx0y_ZUSj0HW-o4+8QYbSqoCx3n-Uw8CaSjJT-A@mail.gmail.com>
Subject: Re: Archiva 1.4 M3/M4 on Raspberry PI
To: users@archiva.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for this analysis !
In last version I moved to use new asyncLogger from log4j2 (see
http://logging.apache.org/log4j/2.x/manual/async.html) which use
disruptor library.
I don't know yet if it's a good idea or not :-) but your value (on a
"classic" env) doesn't look to be an excessive.
Can you try the same analysis with the system property
-DAsyncLogger.WaitStrategy=3DBlock ? (see the possible values in the
log4j2 documentation page).


2013/5/12 Patrice Ringot <okulea@free.fr>:
> Hello,
>
> Just an update about performance. After more work with the 1.4M4-SNAPSHOT
> (as of 5/11/2013) on the Raspberry, I noticed using htop that this versio=
n
> consumes more CPU comparing to the 1.4M3 version in the same context (don=
't
> be afraid by startup time of M3 on the PI, remember: it is indeed a slow
> machine ...).
>
>    1) initial startup time (fresh install, time to go to the alpacas
> banner):
>
>         - 5mn 47s with 1.4M3
>         - 14mn 23s with 1.4M4-SNAPSHOT
>
>    2) when Archiva is not used, htop shows that :
>
>         - the 1.4M3 version consumes no CPU
>         - the 1.4M4 snapshot version has a thread consuming roughly 88% o=
f
> the ARM V6 CPU
>
> So I made the same test on a OpenSuse 12.2 vmware-ized on a i7 + SSD (usi=
ng
> OpenJDK 7 1.7.0_21, 64 bits) and I obtained the following results:
>
>    1) initial startup time (fresh install, time to go to the alpacas
> banner):
>
>         - 20s with 1.4M3,
>         - 20s with 1.4M4-SNAPSHOT
>
>    2) when Archiva is not used, htop shows that :
>
>         - the 1.4M3 version consumes no CPU (just like the 1.3.6 version)
>         - the 1.4M4 snapshot version has a thread consuming roughly 10% o=
f
> the i7 CPU
>
> Archiva on the Raspberry and its preview JDK8 is definitely not a common =
use
> case for Archiva (maybe it will be in one or two years with 2x or 4x more
> powerful boards ?).
>
> But still, the difference exists between the M3 and M4 version on a more
> conventional Archiva target.
>
> Is it something new or did I do something wrong ?
>
> Regards
>
> Patrice
>
> PS: using jstack and the thread pid(dec)/nid(hex) identifier, it seems th=
at
> the thread involved is the same in both cases:
>
> Raspbian/Oracle JDK8:
> "pool-2-thread-1" #28 prio=3D5 os_prio=3D0 tid=3D0x00ec62c0 nid=3D0x1434 =
runnable
> [0x9e644000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
>         at sun.misc.Unsafe.park(Native Method)
>         at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:349)
>         at
> com.lmax.disruptor.SleepingWaitStrategy.applyWaitMethod(SleepingWaitStrat=
egy.java:66)
>         at
> com.lmax.disruptor.SleepingWaitStrategy.waitFor(SleepingWaitStrategy.java=
:39)
>         at
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBa=
rrier.java:55)
>         at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:115)
>         at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java=
:1110)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav=
a:603)
>         at java.lang.Thread.run(Thread.java:722)
>
> OpenSuse/OpenJDK7:
> "pool-2-thread-1" prio=3D10 tid=3D0x00007faa28c6c000 nid=3D0x6082 runnabl=
e
> [0x00007faa76bcb000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
>         at sun.misc.Unsafe.park(Native Method)
>         at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:349)
>         at
> com.lmax.disruptor.SleepingWaitStrategy.applyWaitMethod(SleepingWaitStrat=
egy.java:66)
>         at
> com.lmax.disruptor.SleepingWaitStrategy.waitFor(SleepingWaitStrategy.java=
:39)
>         at
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBa=
rrier.java:55)
>         at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:115)
>         at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java=
:1145)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav=
a:615)
>         at java.lang.Thread.run(Thread.java:722)
>
>
> Le 12/05/2013 09:21, Olivier Lamy a =E9crit :
>
>> 2013/5/12 Patrice Ringot <okulea@free.fr>:
>>>
>>> Hello
>>>
>>> Just for information: the latest snapshot of 1.4-M4 I have downloaded
>>> today
>>> is able to run decently on a Raspberry PI model B (512MB) under Raspbia=
n
>>> Wheezy and
>>> the Nov 12 preview of the Oracle JDK 8 for ARM processors. The UI is
>>> responsive, and the utilization of Maven is very acceptable for a home
>>> network (I have just modified the
>>> -Xmx parameter to 256M instead of the 512MB default).
>>>
>> Good to know thanks for sharing !
>>
>>> The only thing that do not work out of the box is the Tanuki wrapper as
>>> it
>>> is packaged in the current distribution; it is too old to contain the
>>> required ARM files
>>> (the latest one from SourceForge is OK).
>>
>> Due to license reasons we cannot upgrade.
>> License has changed to GPL see
>> http://wrapper.tanukisoftware.com/doc/english/licenseOverview.html
>>
>>> Another thing I have  noted (unrelated to the Raspberry or this
>>> particular
>>> version of Archiva) concerns the content of the wrapper.conf file: it
>>> contains the version of each jar in the classpath. As I initially used =
it
>>> as
>>> a template in my Archiva puppet module, I had a problem when I made the
>>> 1.4-M3 -> 1.4-M4 update "in place" (class not found since the jars
>>> filenames
>>> have naturally changed between these two versions).
>>>
>>> Extract from wrapper.conf:
>>>
>>> # Java Classpath (include wrapper.jar)  Add class path elements as
>>> #  needed starting from 1
>>> wrapper.java.classpath.1=3Dlib/wrapper.jar
>>> wrapper.java.classpath.2=3D%REPO_DIR%/archiva-jetty-1.4-M4-SNAPSHOT.pom
>>> wrapper.java.classpath.3=3D%REPO_DIR%/jetty-server-8.1.9.v20130131.jar
>>> wrapper.java.classpath.4=3D%REPO_DIR%/javax.servlet-3.0.0.v201112011016=
.jar
>>>
>>> wrapper.java.classpath.5=3D%REPO_DIR%/jetty-continuation-8.1.9.v2013013=
1.jar
>>> ...
>>>
>>> So I have changed my way of dealing with this file, but I remembered th=
at
>>> I
>>> did not encountered this problem with the
>>> ElasticSearch service wrapper; actually they manage the classpath
>>> differently:
>>>
>>> # Java Classpath (include wrapper.jar)  Add class path elements as
>>> #  needed starting from 1
>>> wrapper.java.classpath.1=3D%ES_HOME%/bin/service/lib/wrapper.jar
>>> wrapper.java.classpath.2=3D%ES_HOME%/lib/elasticsearch*.jar
>>> wrapper.java.classpath.3=3D%ES_HOME%/lib/*.jar
>>> wrapper.java.classpath.4=3D%ES_HOME%/lib/sigar/*.jar
>>>
>>> Using the * wildcard makes  wrapper.conf and Archiva versions much more
>>> independant of each other.
>>
>> Good idea that's something to test.
>> Maybe only one line with
>> wrapper.java.classpath.2=3D%REPO_DIR%/*.jar
>> Any time to propose a patch ?
>>
>>> Regards
>>>
>>> Patrice
>>>
>>> PS: I have also tested artifacts deletion in the snapshot repository an=
d
>>> it
>>> was OK for me. This is very convenient.
>>>
>>>
>>
>>
>> --
>> Olivier Lamy
>> Ecetera: http://ecetera.com.au
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>>
>


--=20
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy