Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
From: Gregg Wonderly <gergg@cox.net>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: Trunk merge and thread pools
Message-Id: <99AD94A3-A291-4578-910C-46A4347FAA7C@cox.net>
Date: Fri, 4 Dec 2015 17:19:16 +0300
References: <2047eea34872978cb38898ac3c19ebe2@org.tizen.email>
 <pJxy1r00903wcJL01JxzvC>
In-Reply-To: <pJxy1r00903wcJL01JxzvC>
To: dev@river.apache.org

With a handful of clients, you can ignore contention.  My applications have 2=
0s of threads per client making very frequent calls through the service and t=
his means that 10ms delays evolve into seconds of delay fairly quickly. =20

I believe that if you can measure the contention with tooling, on your deskt=
op, it is a viable goal to reduce it or eliminate it. =20

It's like system time vs user time optimizations of old.  Now we are contend=
ing for processor cores instead of the processor, locked in the kernel, unab=
le to dispatch more network traffic where it is always convenient to bury la=
tency.

Gregg

Sent from my iPhone

On Dec 4, 2015, at 9:57 AM, Greg Trasuk <trasukg@stratuscom.com> wrote:

>> On Dec 4, 2015, at 1:16 AM, Peter <jini@zeus.net.au> wrote:
>>=20
>> Since ObjectInputStream is a big hotspot,  for testing purposes, I merged=
 these changes into my local version of River,  my validating ObjectInputStr=
eam outperforms the standard java ois
>>=20
>> Then TaskManager, used by the test became a problem, with tasks in conten=
tion up to 30% of the time.
>>=20
>> Next I replaced TaskManager with an ExecutorService (River 3, only uses T=
askManager in tests now, it's no longer used by release code), but there was=
 still contention  although not quite as bad.
>>=20
>> Then I notice that tasks in the test call Thread.yield(), which tends to t=
hrash, so I replaced it with a short sleep of 100ms.
>>=20
>> Now monitor state was a maximum of 5%, much better.
>>=20
>> After these changes, the hotspot consuming 27% cpu was JERI's ConnectionM=
anager.connect,  followed by Class.getDeclaredMethod at 15.5%, Socket.accept=
 14.4% and Class.newInstance at 10.8%.
>=20
>=20
> First - performance optimization:  Unless you=E2=80=99re testing with real=
-life workloads, in real-ife-like network environments, you=E2=80=99re wasti=
ng your time.  In the real world, clients discover services pretty rarely, a=
nd real-world architects always make sure that communications time is small c=
ompared to processing time.  In the real world, remote call latency is contr=
olled by network bandwidth and the speed of light.  Running in the integrati=
on test environment, you=E2=80=99re seeing processor loads, not network load=
s.  There isn=E2=80=99t any need for this kind of micro-optimization.  All y=
ou=E2=80=99re doing is delaying shipping, no matter how wonderful you keep t=
elling us it is.
>=20
>=20
>> My validating ois,  originating from apache harmony, was modified to use e=
xplicit constructors during deserialization.  This addressed finalizer attac=
ks, final field immutability and input stream validation and the ois itself p=
laces a limit on downloaded bytes by controlling