river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: Trunk merge and thread pools
Date Fri, 04 Dec 2015 14:19:16 GMT
With a handful of clients, you can ignore contention.  My applications have 20s of threads
per client making very frequent calls through the service and this means that 10ms delays
evolve into seconds of delay fairly quickly.  

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

It's like system time vs user time optimizations of old.  Now we are contending for processor
cores instead of the processor, locked in the kernel, unable to dispatch more network traffic
where it is always convenient to bury latency.

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:
>> 
>> Since ObjectInputStream is a big hotspot,  for testing purposes, I merged these changes
into my local version of River,  my validating ObjectInputStream outperforms the standard
java ois
>> 
>> Then TaskManager, used by the test became a problem, with tasks in contention up
to 30% of the time.
>> 
>> Next I replaced TaskManager with an ExecutorService (River 3, only uses TaskManager
in tests now, it's no longer used by release code), but there was still contention  although
not quite as bad.
>> 
>> Then I notice that tasks in the test call Thread.yield(), which tends to thrash,
so I replaced it with a short sleep of 100ms.
>> 
>> Now monitor state was a maximum of 5%, much better.
>> 
>> After these changes, the hotspot consuming 27% cpu was JERI's ConnectionManager.connect,
 followed by Class.getDeclaredMethod at 15.5%, Socket.accept 14.4% and Class.newInstance at
10.8%.
> 
> 
> First - performance optimization:  Unless you’re testing with real-life workloads,
in real-ife-like network environments, you’re wasting your time.  In the real world, clients
discover services pretty rarely, and real-world architects always make sure that communications
time is small compared to processing time.  In the real world, remote call latency is controlled
by network bandwidth and the speed of light.  Running in the integration test environment,
you’re seeing processor loads, not network loads.  There isn’t any need for this kind
of micro-optimization.  All you’re doing is delaying shipping, no matter how wonderful you
keep telling us it is.
> 
> 
>> My validating ois,  originating from apache harmony, was modified to use explicit
constructors during deserialization.  This addressed finalizer attacks, final field immutability
and input stream validation and the ois itself places a limit on downloaded bytes by controlling

Mime
View raw message